Do Me a SOLID…
…Somebody create a better mnemonic. Actually, the mnemonic is fine, the problem is what the mnemonic is trying to remind us of.
(S)ingle Responsibility
(O)pen/Closed
(L)iskov Substitution
(I)nterface Segregation
(D)ependency Inversion
I still go to Google every time I need to think about it. A mnemonic should represent a rational group of words, like Solve Our Logic Issues Dammit! Not some obscure, convoluted word salad that only a software developer could have created.
Maybe I’ve been around too long, but SOLID principles seem like a big collection of No Shit Sherlock’s, and sound suspiciously like the old OOP (Object Oriented Programming) paradigms, including High Cohesion and Low Coupling. Or as I like to call it, HiCo LoCo. And that, my friends, is why you never let a programmer create a mnemonic. Or design a UI/UX (User Interface/User eXperience). We suck at it.
In any case, SOLID principles are just another name for the common sense fundamentals that developers have been practicing for decades. Some day we’ll be good at them <Rim shot>. Let’s take a look.
Single Responsibility Principle
Every class should have one and only one responsibility. This is a weird principle. It seems to imply that every class should implement only one single method or act upon one single variable, which is ridiculous. If you have a logical grouping of responsibilities, logging a user in and out of your app for example, I see no reason to create a separate class for each of those actions.
However, this principle is in keeping with HiCo LoCo in that you want your classes to be as tightly focused, have as few dependencies, and be as coherent as possible.
Open/Closed Principle
A class should be open for extension but closed for modification. This principle will be familiar to anyone who has done any kind of OOP. Once your class has been designed and implemented, no one else should need to touch the code — assuming you’ve designed the class to be extensible.
For example, you’ve written a Login class that can log in with Google, but later your boss says we also need to log in with FaceBook, so now you need to go back and modify your class. You’re a knucklehead. Obviously, you don’t want to waste time coding for features that will never be asked for, but that one was a no-brainer.
Liskov Substitution Principle
Sounds scary, but it’s actually a big, Duh. We should be able to substitute a subclass for the parent class without affecting the behavior of the program. If you’ve written a subclass that you can’t slot into your existing code without breaking it, you need to go find another line of work.
Interface Segregation Principle
Developers shouldn’t be forced to implement interfaces that they don’t use. This principle is my favorite. It implies that we refactor our code as we develop, which I highly recommend.
For example, you now have a very useful Login class that can log your app users in with both FaceBook and Google, but your boss just got a memo from legal saying FaceBook has sent you a cease and desist, so now we can only login with Google. You’re still a knucklehead. You need rewrite your Login class so that it doesn’t require developers to implement both authentication methods.
Dependency Inversion Principle
High-level classes, which provide complex logic, should not be dependent on low-level utility code. Again, this is basic HiCo LoCo and the way to do it is to use abstractions.
Using our login example again, instead of writing the login code for all of our 3rd party authenticators in the Login class — or even writing and directly instantiating new 3rd party authentication classes, and consequently dragging all of their dependencies into the Login class with them — we’ll create an interface with two methods, logIn() and logOut(). Then we’ll implement that interface in a GoogleLogin class and a FaceBookLogin class, and finally, we’ll use that interface in our Login class, thus ensuring the Login class does not have any coupling to either authentication vector.
So, in conclusion, I swear, if someone asks me what SOLID stands for, it is now, and forever shall be, Solve Our Logic Issues Dammit!, because there’s no way I’ll ever remember that other jumble of words and concepts. But, if someone asks what the principles are for, that’s a different story. They’re a basic set of good programming practices that every OOP developer should already be following. HiCo LoCo!
