Why Even Bother?
In the software development world, there are 2 extremes.
People who don't follow best practices.
People who follow th...
For further actions, you may consider blocking this person and/or reporting abuse
My opinion is that these 5 principles are not all on the same "level". Some of them seem quite 'specific' - heavily geared towards classical OO (think Java, or C++).
The one that I think is most useful, still, in 2021, is the most generic one (and the one that's least tied to "classic OO"):
"Single Responsibility"
I'd say that this one is (almost) always useful, regardless of the programming language or paradigm you're using (like OO, FP, and so on).
The more a principle is tied to the specific "classical OO" paradigm, the least relevant it still is in 2021. Well that's what I think :-)
These idea still apply in FP JS:
Every time we call connect() to wire up a React component to Redux or similar, we’ve just practiced dependency injection (props are injected dependencies) & single responsibility (component is not responsible for sourcing its own data).
Similarly, passing in callback functions to a component is following Open/Closed, as you’ve extended without modifying.
Great examples!
Agreed well said.
As a FE developer, when I first learnt these principles in terms of real world use cases many years ago, it totally blew my mind.
I try to follow them as much as possible and I think my code has vastly improved as a result.
The front end ecosystem lends itself more to FP than OOP these days so much of the original SOLID descriptions are not really relevant, but there are ways to interpret them.
SRP and DI in particular are incredibly important principles that I take into consideration in everything I do.
"we should be able to use a child and a parent class interchangeably" - no, not interchangeably. Liskov only states that a subclass should be usableable instead of the parent. Not necessarily the other way around. It's perfectly acceptable to add a method in a subclass.
In fact it's right there in the article you linked.
Updated.
... I initially started by writing an answer that they are relevant and should be used if your language supports them. But I think it's more subtle than that.
For example, in front end, it's rare to apply these principles. Dependency injection seems rare (outside of the Angular framework). Hardcoded imports and usage of dependencies seems much more common. This breaks the open-closed principle in many cases.
Interfaces are not used either (JavaScript doesn't have them). Even when using TypeScript, interfaces are often used because they must be used for type checking, rather than to apply the dependency inversion principle.
But maybe it's okay. Each layer of abstraction has benefits, but also increases complexity. If the benefits aren't worth it, then maybe it's okay to ignore them. Dependency injection and interfaces aren't as useful if there is only ever a single implementation. There are ways to unit test without them and having to recompile isn't too bad.
But, my personal preference is to use them. I prefer Angular in this aspect compared to other front end frameworks. So in the end, I agree for the most part. I'd say to always use the single responsibility principle and the open-closed principle as much as possible. As for the rest, be pragmatic and start using them early if they'll provide a real benefit to the project.
I think the SOLID principles are just as relevant now as they’ve ever been, and FP languages still benefit from applying the values behind them.
The thing a lot of developers miss about SOLID: they’re about useful shapes for indirection & abstraction: they can’t tell you whether adding abstraction or indirection is the correct path to take in your setting & context.
As long-time OOer and modeling guru Sandi Metz says, “the wrong abstraction is more costly than no abstraction at all.”
And it’s precisely because introducing abstraction & indirection bear design cost that the SOLID principles are useful & relevant!
So:
Part 4 : a class do not extends interfaces but classes. Typo of extends
My bad, I will fix it. Thanks 👍
well written, well structured. thanks for this!
Yangi => yagni
SOLID is very old by now, better give it a check to WET -> deconstructconf.com/2019/dan-abram...
SOLID principles are simply good OO design practices, that exist since the 80s. Nothing new under the sun.