SOLID and the other OOP principles (KISS, YAGNI, DRY/WET, GRASP, Package Principles, et cetera) are all band-aids for shortcomings in OOP.
(Them's fighting words!)
Before we had OOP, we had procedural programming. OOP became the hot new paradigm to cure all our woes with procedural programming. And prior to OOP, procedural programming itself had changed over time with the advent of structured programming.
Well, OOP did cure many of our woes with procedural programming. But after years and years, OOP created some of its own woes. SOLID (and friends) are to address the woes that OOP brings to the table.
In time, I expect a new programming paradigm to become the next hot new paradigm, and unseat OOP. (OOP will never "go away", it'll always be around. Just like procedural languages are still around. It'll just become less prominent.)
Will the next craze be FP (like C# with LINQ)? FFFP (like F#)? DSL (like JetBrains MPS)? PPL (like Lisp)? Algebraic (like Mathematica)? Retro revival (like beautiful and concise APL)? Simonyi's Intentional Programming? Knuth's Literate Programming? DOD (like Blow's Jai)? Something else? Exciting times!
Sorry, but paradigms are not religion. You don't have to be either Catholic or Protestant.
There had been different ideas on what OOP should be in the past, but as implemented in C++ it was just a way to isolate parts of your code, thus reducing complexity. And it was a clever way to reuse code without loosing the single source of truth. It was never a holy grail the cured all your programming issues, specially with an increasing number of people that did not even know how to use these tools.
And how should they? Javascript initially had no class concept, and what we have now is only a very lightweight shadow of what classes should be. No encapsulation, no fine grained scoping.
You should explain a bit more, which "whoes" OOP could not cure? Maybe it is more a problem of your expectation. If you put enough spaghetti into a class, the result will still be spagehtti. This is the same with all paradigms.
Functional progamming makes your programs more reliable. But internally, a class works like a small programm, so there is absolutely no reason why you should not apply the principles of FP to class methods.
OOP was invented to solve the problems of large procedural codebases. But did people switch and write only OOP-code? No, they did not, They continued to write procedural code, nut now inside OOP-classes and only where it was appropriate. Just because we establish a new paradigms, this does not mean, we forget about anything we have learned before. We're just increasing our toolbox, nothing else.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
SOLID and the other OOP principles (KISS, YAGNI, DRY/WET, GRASP, Package Principles, et cetera) are all band-aids for shortcomings in OOP.
(Them's fighting words!)
Before we had OOP, we had procedural programming. OOP became the hot new paradigm to cure all our woes with procedural programming. And prior to OOP, procedural programming itself had changed over time with the advent of structured programming.
Well, OOP did cure many of our woes with procedural programming. But after years and years, OOP created some of its own woes. SOLID (and friends) are to address the woes that OOP brings to the table.
In time, I expect a new programming paradigm to become the next hot new paradigm, and unseat OOP. (OOP will never "go away", it'll always be around. Just like procedural languages are still around. It'll just become less prominent.)
Will the next craze be FP (like C# with LINQ)? FFFP (like F#)? DSL (like JetBrains MPS)? PPL (like Lisp)? Algebraic (like Mathematica)? Retro revival (like beautiful and concise APL)? Simonyi's Intentional Programming? Knuth's Literate Programming? DOD (like Blow's Jai)? Something else? Exciting times!
Sorry, but paradigms are not religion. You don't have to be either Catholic or Protestant.
There had been different ideas on what OOP should be in the past, but as implemented in C++ it was just a way to isolate parts of your code, thus reducing complexity. And it was a clever way to reuse code without loosing the single source of truth. It was never a holy grail the cured all your programming issues, specially with an increasing number of people that did not even know how to use these tools.
And how should they? Javascript initially had no class concept, and what we have now is only a very lightweight shadow of what classes should be. No encapsulation, no fine grained scoping.
You should explain a bit more, which "whoes" OOP could not cure? Maybe it is more a problem of your expectation. If you put enough spaghetti into a class, the result will still be spagehtti. This is the same with all paradigms.
Functional progamming makes your programs more reliable. But internally, a class works like a small programm, so there is absolutely no reason why you should not apply the principles of FP to class methods.
OOP was invented to solve the problems of large procedural codebases. But did people switch and write only OOP-code? No, they did not, They continued to write procedural code, nut now inside OOP-classes and only where it was appropriate. Just because we establish a new paradigms, this does not mean, we forget about anything we have learned before. We're just increasing our toolbox, nothing else.