SOLID Is OOP for Dummies

@misc{bugayenko2017blog0328,
  author = {Bugayenko, Yegor},
  title = {{SOLID Is OOP for Dummies}},
  howpublished = {\url{https://www.yegor256.com/170328.html}},
  year = {2017},
  month = {mar},
  note = {[Online; accessed 14-11-2025]}
}

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?

“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.