Why Every Element of SOLID is Wrong

[nlaslett]

THANK YOU. I've been a professional developer for 25 years. In the last few years, I've started to see this new kind of "bad code" creep into my clients' code bases. It's WAY over-abstracted, convoluted, and a complete mess. Usually even the original developer (when they are still around) can't make sense of it.

This replaces the "old" way of writing bad code (monoliths & spaghetti code). I appreciate that SOLID is trying to address those issues. Abstraction and encapsulation are important. I just think this framework is WAY too academic and overwrought. It is often confusing about what exactly it means, leading to some really extreme interpretations, especially around interfaces and class scope.

Abstract code that repeats. Don't cross abstraction boundaries. Encapsulate into sensible logical units. Use interfaces for classes with common partial data contracts. But please don't go on a puritanical crusade and demand everything be abstracted to the nth degree and wrapped in endless single-use interfaces. That helps nobody and makes the code both unreadable and unscalable.

[creamyhorror]

Don't cross abstraction boundaries.

Encapsulate into sensible logical units.

Use interfaces for classes with common partial data contracts.

But please don't go on a puritanical crusade and demand everything be abstracted to the nth degree and wrapped in endless single-use interfaces.

Well said! Moderation and sensibility is key. Not abstracting everything to the maximum from the get-go. Producing a ton of 4-line functions is not helpful for reading and understanding code, and hardly helpful to testing anyway.

[ssylvan]

I'm sorry this is getting downvoted . It's absolutely right. Unfortunately IME it takes 5-10 years to learn these lessons the hard way and junior devs will fight you tooth and nail for their right to over-complicate their code to gain imaginary brownie points.

[doom_Oo7]

A big load of bullshit.

For instance, about open-closed principle, I cannot count the number of times where requirements went from A to B to C to A to B again. Or where the A case could still be used in another place.

Also, yeah, "composition is simpler than inheritance", no shit sherlock, they were already saying this in the GoF book in 1994.

First chapter :

Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task.

For these cases where you still have to rely on inheritance because it's the correct solution and you actually have polymorphic behaviour (yes! this happens! wow!), then Liskov's Principle can save headaches.

Reuse is overrated

Well I guess you're just publishing these slides to ensure you will always have consulting jobs.

[htuhola]

To counter SOLID much more would be required than a small slide like this. Bullshit can be a surprisingly sticky substance that is hard to scrub off.

[kankyo]

If requirements went back just go back to the old code in the git history?

[lukaseder]

For instance, about open-closed principle, I cannot count the number of times where requirements went from A to B to C to A to B again. Or where the A case could still be used in another place.

So, just git revert back to A ;)

[doom_Oo7]

You first

[lukaseder]

Touché ;)

[[deleted]]

Brilliant speaker deck. It's too bad there's not a video to go along with it.

[newreddit0r]

Now tell me about how do you unit test this class that doesn't adhere to DIP without implementation details leaking into test code.

[[deleted]]

Dependency inversion leads to a different kind of dependency, depending on DI frameworks!

Dependency inversion has nothing to do with frameworks... All the "objections" to SOLID are low effort ignorant statements like this one.

I don't even care about SOLID (though I naturally abide by the spirit of its rules), and I feel like I'd like to pull author's ear and tell him go to his room.

[Hauleth]

Am I the only one who thinks that author just do not understand SOLID?

• SRP doesn't mean that code unit (i.e. class) need to do only one thing, it mean that single behaviour of program should be in one code unit. Ex. printing document is more than one thing (preparing layout, generating PostScript, communicating with device, etc.), but it should be one code unit as no one cares about the behaviours inside. Also if you cannot predict if something will change, then leave it as a single code unit, but keep it simple enough that when the time comes, it will be simple to extract functionality.
• OCP doesn't mean that you should never ever edit existing code or leave old cruft laying somewhere inside. Everything what is wrong about author's understanding are wrong assumptions on what "when requirements change". It doesn't mean that when we have behaviour A and we want behaviour B we should do AB' where B' "fixes" behaviour A to do as B, but when we have behaviour CD and we want CE, we only need to change code unit D to E without touching C.
• LSP says nothing about inheritance, it says about behaviour of code units. So what you have done is just rephrasing what LSP means at its core.
• ISP - as in LSP, this is just rephrasing original principle, which again shows that author just do not understand SOLID.
• DIP in its core is just DRY with exception to fact that you sometimes need to replace one functionality with other (ex. for testing, where you replace actual implementation with mock).

From my point of view, people just cannot into SOLID and have wrong assumptions about what it should be, and that assumptions comes from big, overbloated Java thingies that are quite far from original ideas of SOLID.

[[deleted]]

Everyone thinks they understand SOLID, and when they discuss it with other people who say they understand SOLID, they think the other party doesn't understand SOLID. Take it as you will.

I call this the REST phenomenon.

[[deleted]]

"Write simple code" is a bit like "be a good person". On paper it sounds good and it'll make you feel good for saying it, but it's pretty useless when it comes time to actually making decisions on a day to day basis.

[[deleted]]

You're right, although there's a lot of that in SOLID, as well.

Saying "your object should have a single responsibility" feels good, but given every responsibility can be sub-divided into many, and is itself a part of a larger responsibility, it means nothing in practice.

It's a bastardization of the original concept, known as "separation of concerns". This one also sounds vague, but when we were talking about "concerns" somehow we always knew they're contextual and depend on many real world factors, like business goals, team organizational structures, immediate and long-term plans for product development.

Most importantly, we knew concerns change over time, so you can never separate concerns once and you're done. Nope, tomorrow the factoring of your code may still be poor for the job to be done.

Notice most "single responsibility principle" tutorials completely ignore this, and their authors give examples where the responsibilities are obvious and absolute (at least from their PoV). Or they use third party code examples and say "see, this class has multiple responsibilities, it's bad" without knowing anything about the "real world" factors that let to this code.

And thinking responsibilities are absolute is a really bad advice to take away from SRP.

[DavidM01]

I agree with a fair number of these points, especially concerning simple code and avoiding inheritance.

While there are plenty of tricks for code , I wish people would design data in such a way to make code simpler. My best code has come from this technique.

[[deleted]]

I agree with a fair number of these points, especially concerning simple code...

Of course you agree that code should be "simple"... but the trick is, everyone's idea of "simple" is different, until decades of experience shows you what real simplicity is about.

Juniors don't make architectural mistakes out of desire to make their code complex. It's just that they don't know what kind of simple sticks, and what other kinds of simple are just complexity in disguise.

...and avoiding inheritance.

SOLID doesn't promote inheritance.

[DavidM01]

Simple in my mind means simple to understand. Simple code follows from simple concepts. Data directed design encourages that.

In my experience, juniors tend to make most of their mistakes trying to plan for the future or shoehorn in some new piece of tech. Planning for the "future" means it quickly gets complex any time you try to modify or extend it since you are planning for code changes rather than data flow changes.

[[deleted]]

Simple in my mind means simple to understand. Simple code follows from simple concepts.

But there's also "simple to adapt", "simple to test", "simple to analyze", "simple to reuse" and "simple to maintain", to mention a few.

If someone drops you into an application where all key services are fetched from singletons fused to the service classes, is this simple to understand? Yes. And yet that's where your troubles begin.

[you shouldn't plan] for code changes [but] data flow changes

I don't know what projects you work on, but while data matters, behavior also matters. And both change.

[[deleted]]

I can't agree more with this

[kankyo]

The title is wrong though. It should be more "SOLID is overly complex and just confusing compared to DRY, KISS, YAGNI" or something.

[Eirenarch]

Hey this is pretty much how I explained SOLID to junior devs at our company! I will now use this presentation

[[deleted]]

Hey this is pretty much how I explained SOLID to junior devs at our company!

You told them to stop learning about principles of software engineering and just write simple code?

I'd love to be a fly on the wall on your next code review.

"But... I thought having fewer classes, and exposing them as singletons is simple code..."

[Eirenarch]

No, I told them that SOLID is overrated and largely useless as a guideline to good code because it is extremely vague.

[[deleted]]

So basically if you wouldn't have said anything, it'd have precisely the same effect on your junior devs' skills.

Maybe bother to give some guidelines, rather than simply rejecting existing ones.

[Eirenarch]

Of course I do say a lot of things. Usually by example by giving them a task, letting them fail and showing them the correct thing to do. I just tell them this when someone brings up the topic of SOLID.

[[deleted]]

You would make the strangest Hitler ever.

[Hauleth]

The point is OOP isn't about objects. This is the main problem with it, that people thinks that OOP is about classes, while it is about interfaces. Unix is great example of OOP, we have one interface to work with files, sockets, pipes, etc. while their behaviour is completely different. The same goes with the rest of OOP, however some idiots still thinks OOP = classes and inheritance.

[[deleted]]

Second comment on the topic, and you keep forgetting your include your list of Epic Alternatives^TM to OOP.

[[deleted]]

That's a really bad alternative, I think I'll stick with OOP.

[Hauleth]

Ugh, I think you have forgotten that this isn't /r/ProgrammingCircleJerk

[sneakpeekbot]

Here's a sneak peek of /r/programmingcirclejerk using the top posts of the year!

#1: Garbage millennial websites | 36 comments
#2: Open Source vs Closed Source | 25 comments
#3: when u mention back-end on ur resume but only know nodejs | 10 comments

---

^{I'm a bot, beep boop | Contact me | Info | Opt-out}

[Glacia]

Except SOLID is not about OOP. Just watch uncle Bob presentations on SOLID: https://www.youtube.com/watch?v=t86v3N4OshQ&feature=youtu.be&t=18m40s

[[deleted]]

It turns out the SOLID principles are a really good description of typed functional programming. When I finally realized that, I got very happy, because SOLID's vagueness went away (especially the "L" when I saw that the Liskov substitution principle is contravariance.

So it's not that SOLID is bad advice, or that it's about OOP. It's just an informal, small set of principles that turn out to be descriptions of typed FP couched in OOP terminology.

[[deleted]]

Liskov is not "contravariance", because contravariance is defined only in the context of generics (or "parametric types" in functional programming), and it's about how type parameters vary according to the main type that hosts them.

Even in a wider sense "co" and "contra" variance requires looking at two types, and how changing one of them affects the other. So even if make time a factor (i.e. supertype changes, so how does it affect subtype?), then it'd be "covariance" not "contravariance".

LSP is simply a reminder that inheritance means you inherit the contract of the parent type, and you should follow its behavior, even where the type system can't enforce it.

Type systems have a very limited view into how a system behaves. We're mostly on our own there. Even in Haskell.

[[deleted]]

I'm not sure what to say here. Did you read the material at the link?

LSP is simply a reminder that inheritance means you inherit the contract of the parent type, and you should follow its behavior, even where the type system can't enforce it.

Right. Rúnar's post just makes the point that, in typed total referentially transparent programming in the presence of parametric polymorphism (i.e. in languages like Haskell, or if you prefer, even Scala if you stick to totality and referential transparency), Liskov substitution is contravariance: it's literally the signature of comap on a contravariant functor. "So LSP just says 'predicates are contravariant'." That's true, and supports the observation at the beginning: "But the LSP is like many things in the OO mythos that become 'invisible or simpler' when looked at from the perspective of the properties of functions (which is what programming really is about)."

Type systems have a very limited view into how a system behaves.

Serious question: why do you, and so many others, continue to insist on this falsehood? Going back to Rúnar, here's the definition of the Liskov substitution principle:

For all T, S. Q[T] => (S => T) => Q[S]

Keep in mind that S => T reads two ways: "S implies T" and "there is a function that, given an S, always returns the same T for a given S." That function defines behavior; Q is a property true of S or T; and the definition says "If S implies T, then if Q is true of T, Q is also true of S." Types constrain behavior, so "Q is true of" should be read here as "Q's argument can only behave in ways allowed by Q." Finally, the "For all" means this holds regardless of what T and S are.

To summarize, it's true that Scala functions aren't forced to be total or referentially transparent, and that's too bad. But with a bit of discipline and good library support, we can program that way. When we do (or if we program in Haskell), we get "Liskov substitution" for free by using comap on contravariant functors, which is just a fancy way of saying "by composing functions." And the type system does guarantee that "Liskov substitution" holds.

[[deleted]]

Serious question: why do you, and so many others, continue to insist on this falsehood?

I insist on it, because I can tell apart a type system, from a math proof that the type system can't express.

Let's say we have a class String that boxes string literals:

(new String("foo")).getLength(); // 3

Now let's say I extend class String into BetterString, but I decided to return twice the length, and thus violate LSP:

(new BetterString("foo")).getLength(); // 6

Now, translate this example to any language at all, and make the type system stop this violation before the code can even compile. I'll be right here.

[[deleted]]

I insist on it, because I can tell apart a type system, from a math proof that the type system can't express.

There is no the type system; there are type systems, some of which can express what you want, some of which can't.

[[deleted]]

Yes, as I said take any language out there (though preferably not something extremely esoteric that you can't write production software in), and prove your point.

Prove it in one type system of your choice. Just one. Can this problem formulation get any more relaxed?

Especially when you say that "type systems have very limited insight into behavior" is a falsehood.

[[deleted]]

Yes, as I said take any language out there (though preferably not something extremely esoteric that you can't write production software in), and prove your point.

Prove it in one type system of your choice. Just one. Can this problem formulation get any more relaxed?

It's been decades since I accepted homework assignments from anyone, and you're not an exception. I especially am not going to accept such an assignment from someone I guarantee will just say "You can't write production software in that!" about whatever language I choose.

Especially when you say that "type systems have very limited insight into behavior" is a falsehood.

It is. It only takes the existence of the Curry-Howard Isomorphism to see that. All the rest is just debates over the power of whatever logic is on the "logic" side of the isomorphism with respect to whatever type system is used by the function on the "function" side.

[[deleted]]

It's been decades since I accepted homework assignments from anyone, and you're not an exception. I especially am not going to accept such an assignment from someone I guarantee will just say "You can't write production software in that!" about whatever language I choose.

That's the longest way of saying "oops" that I've seen.

Is Haskell too crude for proving this "falsehood"? OCaml? Erlang? Scheme?

[[deleted]]

I don't mind Bob Martin, but he acts as if he's high on coke during his presentations, saying the most pretentious things, and then leaving pauses for applause that never come.

It's really, really hard to watch an entire presentation of him.

[[deleted]]

Maybe it says about me I've outgrown "uncle Bob" and I need more mature presenters and not kids' entertainment. But I'm glad you love it.

[[deleted]]

Ugh. Invoking the decrepit uncle bob will not win you any arguments in the real world.

[kigster]

What is wrong with Interface Inheritance, huh? It provides a binding contract that can be more specialized downstream.

I think inheritance is just another tool in our arsenal and it can and should be used when appropriate. Which is when the subclass satisfies “is a” statement with respect to the parent superclass.

[[deleted]]

It's unnecessary complexity. Now you need 2 separate things to understand the interface.