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 :-)
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.
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 :-)
Agreed well said.
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!