You definitely know the SOLID acronym. It stands for five principles of object-oriented programming that, if followed, are supposed to make your code both legible and extensible. They were introduced almost 30 years ago, but have they really made us better programmers in the time since? Do we really understand OOP better thanks to them? Do we write more “legible and extensible” code? I don’t think so.
Let’s go one by one and see how they “help.”
S
The “S” refers to the Single Responsibility Principle, which, according to Clean Code by Robert Martin, means that “a class should have only one reason to change.”
This statement sounds extremely vague to me, but the book explains it, stating that objects must be problem-centered and responsible for “one thing.” It’s up to us to decide what that one thing is, of course.
This is what we know as “high cohesion” since Larry Constantine wrote about it in the IBM Systems Journal in 1974. Why was it necessary to create a new principle 15 years later with an ambiguous name and a very questionable definition?
O
This letter is about the Open/Close Principle, which was introduced by Bertrand Meyer in Object Oriented Software Construction in 1988. Simply put, it means that an object should not be modifiable. I can’t agree more with this.
But then it says it should be extendable, literally through implementation inheritance, which is known as an anti-OOP technology. Thus, this principle is not really applicable to objects and OOP. It may work with modules and services, but not with objects.
L
The third letter is for the Liskov Substitution Principle, which was introduced by Barbara Liskov in 1987. This one is the most innocent part in the SOLID pentad. In simple words, it states that if your method expects a Collection, an ArrayList will work.
It is also known as subtyping and is the foundational component of any object-oriented language. Why do we need to call it a principle and “follow” it? Is it at all possible to create any object-oriented software without subtyping? If this one is a principle, let’s add “variables” and “method calling” here too.
Honestly, I suspect that this principle was added to SOLID mostly in order to somehow fill the gap between “SO” and “ID.”
I and D
I guess they both were introduced by Robert Martin while he was working at Xerox.
The Interface Segregation Principle states that you must not declare List x if you only need Collection x or even Iterable x. I can’t agree more. Let’s see the next one.
The Dependency Inversion Principle means that instead of ArrayList x, you must declare List x and let the provider of the object decide whether it is ArrayList or LinkedList. This one also sounds reasonable to me.
However, how is all this different from the good old “loose coupling” introduced together with cohesion by Constantine in 1974? Do we really need to simplify and blur in order to learn better? No, not to learn better, but to sell better. Here goes my point.
My point is…
The point being these principles are nothing but an explanation of “cohesion and coupling” for dummies in a very primitive, ambiguous, and marketable way. Dummies will buy books, seminars, and trainings, but won’t really be able to understand the logic behind them. Do they really need to? They are just monkeys coders, right?
SOLID is a money-making instrument, not an instrument to make code better.
“But an object must be responsible for one thing!” is what I often hear at conferences. People learn that mantra without even knowing what cohesion is nor understanding what this “one thing” they are praying for really is. There is no such thing as “one thing,” guys! There are different levels of cohesion.
Who is guilty? Uncle Bob & Co.
They are no better than Ridley Scott and other Hollywood money makers who deliver primitive and easy-to-cry-at movies just to generate a profit. People are getting dumber by watching—but this is not of their concern. The same happens with magic OOP principles—programmers rely on them, thinking the truth is right there while the real truth is not understood even by the creators of this “magic.”
SOLID is a money-making instrument, not an instrument to make code better.
You may also find these related posts interesting: Command, Control, and Innovate; Synchronized Decorators to Replace Thread-Safe Classes; Inheritance Is a Procedural Technique for Code Reuse; Redundant Variables Are Pure Evil; A Compound Name Is a Code Smell;
| Reference: | SOLID Is OOP for Dummies from our JCG partner Yegor Bugayenko at the About Programming blog. |
Another oppinionated article from an author who cant write a single class normally (read a lot of article and code from author).
Read more, get some humility. Anyway pure OO is past.
Regards
Liskov is the only one that has a formal definition. So because you don’t understand it you are using some form of logic fallacy?
I agree completely. Each one of those principles is badly written, ambiguous and open to massive amounts of interpretation. They are not good enough as teaching aids for newbie programmers, but the biggest problem is with the more experienced programmers who think that they know what they are doing and who then insist that THEIR interpretation is the only valid interpretation, and anyone who does not follow their dictats is not doing OOP “properly” and needs to be re-educated. My work has often been criticised by such people, but I refuse to accept their “advice” as their interpretations are far… Read more »
Which ERP system?
The original name was TRANSIX, but it is now being marketed under the name GM-X by http://www.geoprise.com
Excellent criticism, never thought of that but the fact that the initials worked so well to spell SOLID should have been an indicative of waht was in their minds while writing their book. (“We need a powerful acronym to sell our idea and it doesn’t matter that all the concepts have already been named and described before.”)
> This letter is about the Open/Close Principle … But then it says it should > be extendable, literally through implementation inheritance, which is > known as an anti-OOP technology. Thus, this principle is not really > applicable to objects and OOP. It may work with modules and services, > but not with objects. Nearly all of the examples I’ve seen for the OCP over the past 15 years have used the Strategy pattern. The closest I think I’ve seen to a suggestion to use implementation inheritance was via use of the Template Method pattern. And even there, the example… Read more »
I disagree with much of the criticism here. I don’t have a problem with the ‘renaming’ of principles as it is a way of providing in a simple ‘package’ some of those elements of good design that we should always keep in mind. Robert Martin never claimed that these were original to him. Just that they were critical to good design. I don’t think that he even claimed that the list is an exhaustive list. Just that these 5 principles are at the top of the list of principles to apply when designing a system. I especially find especially off-base… Read more »