DEV Community

Adam Crockett 🌀
Adam Crockett 🌀

Posted on

SOLID is not applicable

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?

Latest comments (18)

Collapse
 
mogui profile image
mogui

The answer is in your own question.
It is not applicable outside OOP context, BECAUSE it is an OOP concept.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

It's not a question it's a gently worded statement about the misuse of a term which has become prevalent in context in which it does not apply.

Collapse
 
benjioe profile image
Benjioe • 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).

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

what is POO?

Collapse
 
benjioe profile image
Benjioe

OOP* thanks

Thread Thread
 
adam_cyclones profile image
Adam Crockett 🌀

I laughed so hard. Thanks for making my morning 😂

Thread Thread
 
benjioe profile image
Benjioe

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

Thread Thread
 
benjioe profile image
Benjioe

Maybe when you know FP, OOP look like poo

Thread Thread
 
adam_cyclones profile image
Adam Crockett 🌀

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

Collapse
 
abhinav1217 profile image
Abhinav Kulshreshtha

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.

Collapse
 
alainvanhout profile image
Alain Van Hout

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.

Collapse
 
pandaquests profile image
Panda Quests

Examples?

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

function (){

}

Collapse
 
htissink profile image
Henrick Tissink

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)

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

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. 🎉😁👌

Collapse
 
htissink profile image
Henrick Tissink

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

Thread Thread
 
adam_cyclones profile image
Adam Crockett 🌀

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.

Thread Thread
 
htissink profile image
Henrick Tissink

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.