loading...

SOLID is not applicable

adam_cyclones profile image Adam Crockett ・1 min read

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?

Discussion

pic
Editor guide
 

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.

 

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).

 

what is POO?

 

I laughed so hard. Thanks for making my morning πŸ˜‚

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

Maybe when you know FP, OOP look like poo

Now that is something I can dedicate ly agree with. πŸ’©πŸ˜†βœ¨

 

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)

 

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. πŸŽ‰πŸ˜πŸ‘Œ

 

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

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.

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.

 

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.

 
 

function (){

}

 

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

 

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.