SOLID is not applicable

#webdev #discuss

I have read the OOP synonymous acronym SOLID being thrown around alot lately. SOLID means... Something but it's not applicable in most contexts outside of OOP. What do you think? Is this true?

Top comments (18)

Alain Van Hout • Sep 21 '20

It goes without saying that all 5 SOLID precepts aren't directly applicable to functional programming, but their underlying principles generally do apply. My take on it would be this:

Single responsibility principle: a function should do one thing, and do it well
Open-closed principle: compose small functions, rather than having a single one that does a lot, since the latter will mean that you'll be changing the code too often
Liskov substitution principle: since this is based on design-by-contract, it could be understood as such: when a function's passed as an argument, you should be able to replace it with another function that adheres to the first one's contract within the first one's scope, although it may have extended functionality beyond that scope (say, instead of passing sumTwoIntegerNumber, you pass sumListOfRealNumbers)
Interface segregation principle: for functions, I think this boils down to S, O and L: keep your building blocks small, and rely on contracts
Dependency inversion principle: instead of your function depending directly on some other function (e.g. a specific encryption function), make it take that function as a parameter, based on a certain contract. That way, you aren't hardcoding that aspect into your function.

Let me emphasize again that these aren't the literal SOLID precepts, but they are their underlying principles. There's also a lesson here when we just focus on OOP: SOLID isn't about mindlessly applying those 5 rules, it's about getting benefits from best practices that have been discovered by trail and error. And as with most best practices, having an understanding of the underlying principles helps you to know when to apply the best practice and when not.

Benjioe • Sep 22 '20 • Edited

SOLID main principe is Open close (he is the first one in the original paper).
Open close principal is the idea thats when you have a new requirement, do not change the original code but create a new function/object who call/is call by te original one.
All the other letters are way to implement open close principal in OOP. But most of them can be adapte for FP too (replace Interface with callback function).

Adam Crockett 🌀 • Sep 22 '20

what is POO?

Benjioe • Sep 22 '20

OOP* thanks

Adam Crockett 🌀 • Sep 22 '20

I laughed so hard. Thanks for making my morning 😂

Benjioe • Sep 22 '20

In france, whe call it "Programmation orienté objet (POO)", in english that's not the same ...

Benjioe • Sep 22 '20

Maybe when you know FP, OOP look like poo

Adam Crockett 🌀 • Sep 22 '20

Now that is something I can dedicate ly agree with. 💩😆✨

Henrick Tissink • Sep 21 '20

I understand the way you're seeing this - the examples around it are very much around an OOP world - but I don't think they have to be.

Take Single Responsibility for instance, at its definition it says that "classes should only have a single reason to change" - however, wouldn't it be a good idea to create structures/components/functions that only have a single reason to change as well?

I think maybe abstracting SOLID a bit, you can find it applicable to most of software engineering. (Most not all lol)

Adam Crockett 🌀 • Sep 21 '20

But this is my point you want the S from solid and nothing else. Single responsibility sounds great!

I built my application using the S principle. 🎉😁👌

Henrick Tissink • Sep 21 '20

let's have a look at Open-Close - "Classes should be open for extension, closed for modification". Apply this to functions - could we say that "functions should be closed for modification, and created in such a way that we can chain/compose them together (think higher-order functions)". Again, I guess it's just perspective. Liskov Substitution is a bit of a tough one tho haha :D

Adam Crockett 🌀 • Sep 21 '20

SO then. A beginner might say I know I'm using SOLID in an FP context but when interviewed, they may find it hard to apply the other principles and perhaps feel a bit silly 🤷‍♂️. Missinformation is the killer of budding careers that could have been. Or perhaps it's not reading up on your design patterns.
Anyway I know I'm guilty, I say stupid stuff all the time. To be corrected years later, Anyways thanks for stopping by.

Henrick Tissink • Sep 21 '20

Haha! I am the king of saying stupid things - I guess the important part is not being scared to do that, and learning from it too.

Abhinav Kulshreshtha • Sep 22 '20

SOLID principles were defined with an OOP architectural concepts in mind. But in 2020, languages find ways to implement OOP patterns without being OOP itself ( like Golang ).

The biggest misconception that I see juniors dev in my area bringing with them is that all 5 of them needs to be implemented together at all times. In daily usage, only S, L, and I is something I find myself thinking about everyday. I don't remember if I have ever intentionally structured any project for Dependency-Inversion. My projects as a whole does get structured with Open-Closed system in mind either by having plugin system, or by having a separate 'core' modules.

My take on SOLID or GRASP is that these are something one should know about and practice around during their training stage, but not consciously think about in real world.