It has finally happened - the first real tech article on this blog. We gonna talk about design patterns and their importance. Today on the menu - SOLID. To be more specific - some critique towards SOLID, meaning my opinion on the bad parts and good parts about them. Excited about the subject? Or the fact we’ll be covering something with dirt (which is always pleasant, right)? Hopefully, you’re excited as I am.
Why this subject
Now, you may be wondering how could I possibly come up with such a novel blog post idea. Well, I don’t claim to be a master of design patterns - the last time I refreshed any years ago. But being at the start of my IT journey I was obsessed with them. As any dev with approximately 1-3 years of experience most probably. Still, after years of writing code, there is not as much knowledge of them as a feeling.
So, there were a couple of signs from the above to write about this subject. The first one was a few weeks ago when a friend of mine (dev too) started a conversation about patterns. But at that time the subject didn’t touch my warm software developer’s heart. The second sign was my pet project. Yeah, I was working on some shit of my own, but I’ll be covering it in the next blog post (dear God, please help me to finish that one). And the third sign was a job interview - I was asked about design patterns there. This was the final punch. After that, it became clear that an article about the patterns was destiny. So let’s get to the business.
Popularity of SOLID patterns
SOLID is one of the most known abbreviations in the IT universe. If you’re a software engineer and haven’t heard about SOLID then you are probably a PHP developer. Hahaha, right? Wrong - shame on you if you support this trend. SOLID has been marketed really well by Robert Martin (also well-known as Uncle Bob). He didn’t coin the term itself (Michael Feathers authored it), but he did greatly promote it. I’ve probably seen every single talk on them by Uncle Bob. The first thing to acknowledge is that Mr. Robert is a great speaker, and that’s a big part of why this acronym is so popular. For many-many years SOLID was indisputable truth for me, until recently I’ve dared to give some thought to it.
Letters… Why exactly those?
Let’s go through each letter. But we’ll do it in a slightly different order - SDLOI, instead of SOLID.
S
“S” - Single Responsibility Principle. I would argue that this is the most important one. And not only to programming but to everything where the human mind is involved (where it tackles complexity to be more precise). There is a great talk by Rich Hickey - “Simple Made Easy”, where the speaker did the best job in the world of making a point about the importance of simplicity. Timeless talk. Simple things are easy to work with, they are easy to reuse, reorder and think of. Caesar would probably add: “divide and rule”. One of the main things that make things simple is having just one responsibility. If a software engineer knows well only this single principle he/she already has a good chance to be a very good engineer. As simple as that. Also, you see how the importance of this principle is encoded in its name - single the most important principle is the single responsibility principle. Okay, I admit - pathetic attempt on words play.
D
“D” - Dependency Inversion Principle. At least for me this one is the second most important because it’s about abstraction. The most common explanation of this principle is - higher-level modules should not depend on the details of lower-level modules. Which makes a lot of sense. Without following this principle I don’t know how the same app would be migrated to different platforms. Which, of course, is not the only use case. This principle is not solely for “separating business logic from OS” - no doubt it’s useful on every layer of an app. So yeah, this one is neat too.
L
The next one is “L”. And this is the moment when stuff starts turning South. “L” stands for “Liskov Substitution Principle”. The broader explanation is kind of complicated, so I won’t even bother. In short - it is about polymorphism. Just about old good polymorphism. To be fair - polymorphism is kind of a big deal too, so the letter is legit. But why use “L” instead of “P”? Maybe because SOLID is more catchy than SOPID? The principle is fine, but it lacks authenticity. One should always be yourself.
O
“O” - Open Closed Principle. It should be easy to add stuff to your code without modifying it. Or, speaking the original language, - your code should be opened for extension and closed for modification. In theory, it sounds good. I mean who wouldn’t want to easily add behavior without breaking the existing code. It’s a wet dream of every software engineer. But, at least from my experience, the reality is a bit harsher. Yes, there is a code that is more prone to change, and a code that has a good chance to stay still. Separating one from another seems like not a bad idea at all. But there is one tiny thing, just one problem - it’s hard to predict the future. At some point requirements change and you just have to touch the “sacred closed for modifications code”. Hence, this one is the most questionable principle so far (but wait until we get to “I”). It’s about adding structure to your code, and I would say that GoF patterns serve a better purpose for structuring the code, and “O” may be a bit of an alien here.
I
Now “I”. Interface Segregation Principle. We’ll be short on this one. I don’t get this one at all… Separate interfaces? Isn’t it the same idea as Single Responsibility Principle? WTF? To complete the SOLID word? (Mic drop). Yeah, never used this one (but what I know - just a stupid PHP dev).
The good parts
You caught me - maybe I was in a bit of a dramatic mood while writing the article. Now we’ll try to recover from this rock bottom. The truth (the real truth) is two-fold: (1) One has earned the to critique SOLID principles (2) if he/she use them for at least 9 years (accidentally I fit there).
The first point - yeah, because I’m trying to incorporate those patterns into my daily work for so long, I think I have something to say about them. But let’s be clear (disclaimer) - it’s just my opinion, and I might be wrong.
To be fair - SOLID is important! Why? Because any kind of convention is great. If there were no SOLID software industry would have lost a tremendous amount of quality. Without them, it could be that in 2023 the world would just be getting ready for a… dot-com boom. It’s an exaggeration of course, but I’m trying to make a point that SOLID is a shared knowledge of code quality that software engineers are acquainted with very early in their career thanks to Uncle Bob.
SOLID might not be a perfect creature. But who or what is perfect? Given how much goodness SOLID did we must just embrace the imperfect parts of it and be grateful that they are there and that they are visible enough. Except maybe fucking “I”.