SOLID is Outdated

I’ve been writing software for about 25 years now, and much of that time has been spent writing that software in Object-Oriented languages. I’m also the type of developer who is always looking to improve my skills. So naturally, early on in my career, I was taught and (generally) followed SOLID Principals. However, I’ve decided after years of debate, that SOLID, at least expressed as such, is pretty much completely useless.

Now, I know this may be heresy to some, but hear me out.

Breaking It Down

Don’t get me wrong; you absolutely should be following the general ideas behind SOLID in object-oriented languages (for the most part). What I take issue with is how they are presented. Let’s take a quick refresher course.

Single Responsibility Principle

A given class/module/what-have-you should be responsible for a single aspect of the functionality of a codebase.

This idea is, in my opinion, the only idea from SOLID that stands on its own pretty much unmodified. My only real problem is how incomplete it is. Yes, it’s absolutely a good idea to organize your code such that functionality is contained within classes/modules/etc., but there’s so much more to this.

Open-Closed Principle

A given function/class/etc, should be open to extension, and closed to modification.

This, in my opinion, is an almost completely useless idea in practice. The reason for this is pretty simple: requirements change.

I’ll grant you that if you’re writing, for instance, the .NET BCL itself, this absolutely makes sense. But if you’re writing something under this category, you’re following a completely different (and much more complete) set of principles all together.

But in the real world, if you have a function called TransformPersonToContact() and the model behind Person or Contact changes, you need to modify the function. Anything else is going to lead to chaos.

Liskov Substitution Principle

Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.

OR

You should be able to swap out dependencies without breaking your code (duh 🙄).

I’ve always found this to be the most uselessly esoteric item in this list. Admittedly, my more simplified version above isn’t exactly what Liskov Substitution is expressing, but to really understand what it’s saying, there are so many other principles you need to understand. Which comes to a much deeper problem around SOLID’s use in the real world, but that’s an article for another time.

Not only that, I personally find much of this idea to be better expressed as the Strategy Pattern, which is great on its own, but SOLID is supposed to be a set of principles, not patterns, which is an important distinction.

Interface Segregation (and the rest)

This is where this whole initialism really starts to fall apart. Our previous principle (Liskov Substitution), Interface Segregation Principle, and Dependency Inversion, are all essentially covering the same single idea:

Use Dependency Injection/Inversion of Control to keep your code flexible and testable.

So why split this up into three separate principles in the first place? DI/IoC is a both simple and incredibly complex topic that can’t be accurately or completely covered by three quick rules.

Wrapping It Up

Again, I need to be clear that much of the ideas in SOLID (except Open-Closed), are great general rules to follow in most scenarios. What I take issue with is how they are packaged.

Every young developer applying for a job in which OOP languages are used knows the question of “explain SOLID to me” is coming, but in all honesty, this is doing everyone involved a disservice. Not only is much of this set of descriptions often incomplete and misleading, leaving new developers with more questions than answers, but many times the interviewers themselves are happy to hear just the surface level answers, not digging into what those things actually mean.

So what’s the solution? Simple… ditch SOLID and break it down to just 3 things:

• Read and understand The Programmer’s Oath.
• Learn and apply the principles of Dependency Injection and Inversion of Control
• Buy and read The Gang of Four Book, then read it again once a year.

Yes, that’s technically much more information and effort, but that’s the idea. Our job is complex, and needs to be understood complexly.