SOLID is not Solid: Five Object-Oriented Principles To Create a Codebase Everyone Will Hate

by David Bryant Copeland

Object orientation is a lie. Reusable, flexible components have failed. The SOLID Principles of Object-Oriented Design still cling to these lies, sending developers down so many wrong paths. In less than 70 pages, this book presents five broadsides against each principle, tracing their history, demonstrating their flaws, and taking their advice to an hilarious degree all to prove a point: you can build good software by focusing on the problem at hand, and discussing the code you're writing, not some nebulous set of principles.

Genres: Technology, Nonfiction

70 pages, Kindle Edition

Published January 12, 2020

About the author

David Copeland is a programmer and author. He wrote "The Senior Software Engineer" and "Build Awesome Command-Line Applications in Ruby", and has over 16 years of professional development experience. He's managed high-performance, high-traffic systems at LivingSocial, helped build the engineering team at Opower, and worked consulting gigs both large and small. Currently, he's a lead engineer at fashion start-up Stitch Fix, building a platform that will change the retail shopping experience.

Reviews

[Adolfo · Rating 3 out of 5]

The most valuable thing from this book for me was to read something that criticises a topic that people keep re-affirming as the truth, unfortunately sometimes without questioning anymore. I remember when I read Clean Code and started agreeing with everything on that book in the beginning. I remember creating tons of private methods to make my code more readable which lead to other problems such as dealing with mutable arguments and so on. But fortunately I also had the opportunity to work with great developers which allowed me to have great discussions on this topic.

I like the way this author poses the idea of questioning authority and he is brave to make it public formatted in a book. I am not going to give 4 or 5 stars because there are a few arguments against SOLID that doesn't make sense IMO (Specially after reading Robert Martin's paper as part of the exercise of reading this book).

Directly relating Dependency Inversion Principle with XML for dependency injection isn't correct. And the fact that Robert Martin says that our code should depend on abstractions doesn't necessarily means that everything all the way up to the main method has to be dynamic and generic enough to cope with this principle. This argument IMO was just the author wanted to disagree just to disagree.

In terms of Interface Segregation Principle I partially agree that it's all about making things cohesive (even interfaces). But it's not useless principle in my opinion. Of course most of principles better apply to statically typed languages and I agree with that. But that's not a reason to ignore SOLID and Clean Code.

Still on ISP I think that the author's comment is just demeaning Uncle Bob's paper on the subject. What does it mean to read the backstory and coming up empty? With all due respect, I think that this is not a good argument against the principle.

Another thing that I don't like in this book is the idea of considering the SOLID principles harmful because developers will just follow them like zombies. Once again on ISP, I haven't seen people creating a 1:1 relationship between interfaces and methods just to satisfy ISP. This would simply be a problem of a lack of maturity of any developer reading any book (not just Clean Code or Agile Principles Practices Patterns from Uncle Bob).

Despite all the things I don't agree, there are also more things that I appreciate on this book: his thoughts on chapter "Agile's infantilising sloganeering diminishes us all". This is by far the best chapter of this book in my opinion. I really love the way the author presents the problems of aphorisms from XP that in some way brings a few acronyms such as BDUF, KISS, YAGNI and DRY. I have seen this kind of stuff on PRs and now I can realise how demeaning some of these are. Specially the KISS acronym which now seems the most stupid one IMO. Also, bringing the BDUF to the table in order to avoid design at all costs and just start coding to prove yourself as a good programmer just create a poor working environment. IMO this goes against inclusion and diversity.

It was a great exercise to read things that I don't agree. And because it's something you don't agree, that doesn't mean that it's something to ignore. It's good to be aware of things we don't agree.

[Osvaldo Santana Neto · Rating 5 out of 5]

The book is really short, objective, and good. But it is not perfect (no book is). I think that he missed the opportunity to propose an alternative to the scenario where all these "acronyms" provide some help to developers that are creating solutions for some problems which they really don't have enough knowledge about.

Let me give an example to explain what exactly I'm trying to say.

It's quite common to be hired to create software that solves some problems. But usually, the developer doesn't know exactly how to solve this problem in the best way since from the beginning. He will learn more about the problem and how to solve it in the best way through the process of developing the software.

But we need to start something, and we can rely on some different approaches to start solving this problem:

1. Big Design Up Front: developer starts to study everything that he can learn about the problem and start architecting a definitive solution for it. Pros: good enough solution if everything goes fine. Cons: high risky of failing on the solution. The customer needs to wait for some time until he starts to have the benefit of the solution.

2. "Standard" practices of software engineering like SOLID/DRY/YAGNI/KISS/Agile/etc: you can start creating the solution using an Agile approach and some 'standard' architecture that enables you with a flexible-enough solution that could be changed between iterations. Pros: "Nobody Gets Fired For Buying IBM". Lots of developers already know these patterns and practices. Cons: you will get an overengineered solution for the problem just to make it more flexible.

3. Test-Driven Design + Refactoring / Agile: you will be literally guided by the code in the process and change the code (refactor) when needed. Pros: you will learn about the problem in the process and you won't spend time with high complexity on the code. Cons: it's really hard to "teach" this mindset for a young developer or to change the acronym-mindset in an already dogmatized senior developer.

I believe that there are more approaches than that I'm pointing but I never tried them to write something about.

[David · Rating 4 out of 5]

I enjoyed this thoroughly. I'm delighted to keep a physical copy of this book on my shelf as a talisman: sometimes I don't understand why I can't see the Emperor's New Clothes and it is SUCH A RELIEF to have somebody say, "Hey! The Emperor is naked!" Thus it was with "SOLID", which, unlike so many guiding principles in software engineering, has always seemed like pure nonsense to me. (I also despised Martin's "Clean Code", so let that guide your opinion of this opinion.)

[Alex · Rating 3 out of 5]

Nice ~series of blog posts~ book. I don't agree with all the author's views but that's only human. Over all they do have some reasonable advice. And the bashing of uncle Bob and the XP crew alone is worth the admission price. It also looks like the author did their research, and the linked articles and papers are relevant and the ones used as good examples worthwhile reads.

OK-ish read, but I'd look somewhere else for advice on software design. If I had to suggest other books (and nobody asked me, but, hey, it's my review) I'd go with John Osterhout's "A Philosophy of Software Design". Barbara Liskov's "Program Development in Java" is also a good read.

[Daniel Gomez Rico · Rating 2 out of 5]

I have some mixed feelings around his ideas, I don't put 1 star on it because he offers some good critics to the Software building process itself, but on the other critics, he says that SOLID is totally bad, and that nobody should use it and ignore and that you should coherce your buddies to do the same thing, wait.. WHAT?

He criticism over each SOLID letter is analysed as a separate concept were all of them should live together.

I see sometimes that these principles/ideas are demonized under the premise that the hole idea of using them is flexibility, that I would be able to replace one database for another, and not, it is not the only gain from them, it's one from a thon.

Be careful about reading this book and take his lessons to not redo them.

[Marcelo Barros · Rating 4 out of 5]

Desde a faculdade sempre tive uma pulga atrás da orelha: como organizar o código, como projetar o código de forma coesa e organizada. Sempre atento a discussões como “fat controller vs skinny controller”. E recentemente a discussão se resume a repetir alguns acrônimos, sem nem saber o que de fato aquilo significa ou o por quê aquilo deve ser aplicado. O livro trás um pouco de luz sobre desafiar esses princípios e tentar entender o que se busca em um código bom. Acho que tem algum exagero quando se fala de alguns princípios do SOLID, mas em geral uma boa leitura.

[Andy · Rating 5 out of 5]

SOLID is principles without nuances.. single responsibility is more about business domain and context.

[Marek Kowalcze · Rating 4 out of 5]

Short but to the point. A good reminder to question old "truths", which might be already outdated.

[Ling Wang · Rating 2 out of 5]

A quip, not as solid as the books that it criticizes.

[strager · Rating 1 out of 5]

Hot garbage.

Super poorly researched.

Perhaps it's downright maliciously researched.

For example, the author criticizes a paper and says:

> Remember, [the open-closed principle] is a principle so the implication is not some classes, but all classes.

but the cited paper says this:

> Modules that conform to the open-closed principle have two primary attributes.

and this:

> It should be clear that no significant program can be 100% closed.

---

In another place, the author says:

> [Martin is] quoted as saying: "a responsibility is a reason to change"
>
> [...]
>
> [...] We don’t have a lot of clarity here.

If the author didn't have clarity, he should have found Martin's quote and listened to the context around the quote. Instead, the author made a bunch of assumptions about what the quote might mean, and criticized Martin for the vagueness of the claim.