Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

A critical examination of the SOLID principles in object-oriented programming. The Liskov substitution principle is endorsed as mathematically sound and universally applicable. The open-closed principle is deemed obsolete in modern languages with proper tooling. The single-responsibility, interface segregation, and dependency inversion principles are criticized as misguided heuristics that lead to over-engineered code. The author argues for focusing on module depth (small interfaces with substantial implementations) rather than blindly following SOLID, and advocates injecting dependencies only when genuinely necessary rather than as default practice.

A SOLID Load of Bull

While i also think we reached a point where we can go beyond SOLID, i think some of the critics are misplaced.
I like his comment about LSP, people usually tend to misunderstood it, but its a really good one to follow beyond just satisfying the type system.
The OCP i don’t think its obsolete, it just means you should design modules for extension, instead of fixing the same code all the time and spreading the impact of the changes over the codebase everytime something changes, this isn’t just a hassle, because even if the compiler enforces you to fix every call site, this takes a lot of time since you need to reavaluate the pre-conditions and maybe the post-conditions for that sub-routine over all the call sites at a case per case basis, better than having the compiler to tell you to fix its not needing to fix at all.
About the C++ example, i don’t understand C++ well to comment, but for languages with nominal type systems like Java, its a problem depend on concrete classes, because you really are tying the client to one and only one class, so every change needs to be done by modification not by extension, this because you don’t want concrete classes depending on concrete classes due to violating LSP more often than not and because of all the well-known inheritance problems
The SRP just means high cohesion, not even low coupling, i think its a good one to always have in mind, its a strategy to achieve high cohesion just like deep modules, both strive for functional cohesion of the original rubric. Also the more fragmented is your team, like in microsservices, the more the advice of be responsible for one actor makes sense.
About the ISP i think the more appropriate critic would be refute the points that Robert comes up in the clean arch book when he discuss the cohesion principles, i think that he thinks more in those terms of balance between 3-axis than a pure application of ISP itself.
DIP is good, i don’t think we should avoid, code becomes harder to test without it, i like the Cockburn point about this, that we always have at least 2 cases for a module the production case and the test case, so we always have multiple implementations, this makes a good case for changing the dependencies.
Also, even Uncle Bob acknowledges that you don’t want to force DIP in everything, in Clean Architecture he points out that you need to make dependencies flexible according to the stability of the module, this is why he accepts entities as the core of the application despite them being concrete modules, even if he says the more abstract ones should be the center of everything

Like a lot of internet articles these days the author wants to generate outrage… where nuance is the better response.
His conclusions are actually decent but too pedantic, they were always principles, not laws, and the coding environment has changed since they were formulated. I actually dislike interfaces, often finding them boilerplate and I avoid inheritance favouring composition. I’ve never treated Single Responsibility as a single action, but as a single intention. This is perhaps the most important principle, as devs routinely create long meandering, unfocused methods that are very long, very hard to work through and present problems when testing! Labeling it to ignore in the article sounds great in writing, very sure and harsh. But some nuance is necessary.
Overall, I think we have to understand how to take these in todays world, if you’re running around enforcing them with the power of divine law, you’re likely creating more hassle and effort than any cognitive load you’re saving. But if I look at your PR and the 400 line method and go… “SRP - what are you trying to accomplish exactly” in the PR comment, I’m likely correct.