SOLID is just a random arbitrary acronym about some principles that are somewhat obvious. However most people don't fully understand these principles deeply. Wh

SOLID is just a random arbitrary acronym about some principles that are somewhat obvious. However most people don't fully understand these principles deeply. What happens is if you are using OOP you are not using SOLID to its full extent. Ironic that SOLID comes from OOP. Either way SOLID are arbitrary rules of thumb. Grouped together arbitrarily to spell out SOLID and kind of maybe sort of right depending on your opinion. 1. SRP. Gather together the things that change for the same reasons. Separate things that change for different reasons. I disagree. Unless this thing is talking about namespacing which is more of an aesthetic/psychological thing... You should not organize your program this way where logic of one thing is tied with the logic of another thing. All things should be ungrouped as much as possible. You should also separate all things that "change" and all things that don't "change" and try to keep the things that "change" as small as possible. All logical modules in your program should be separated as much as possible at the lowest layer, nothing should be grouped... and higher layers should be compositions of lower layers. But the basis of your program at the lowest layer: everything should be separated and nothing should be grouped. In other words use combinators as MUCH as possible. OOP's promotion of methods that operate on shared mutable external scope actually prevent you from doing this. 2. A Module should be open for extension but closed for modification. Agreed. The problem is if your program is OOP your modules are objects which group methods together through shared mutable state. It means that you cannot extend one method without modifying the entire object. So basically OOP practitioners can never modify an addOne method into addTwo. They can't even add an addTwo method into the object as that constitutes modification. What they can do is inject that entire object into another object. Either do this or use inheritance which OOP says is just bad. Instead. Use combinators. You have an addOne combinator? Create an addTwo combinator. Recompose your combinators to form the higher level logic you wanted. 3. A program that uses an interface must not be confused by an implementation of that interface. Yeah I mean sure. Don't have your flatten Function be able to operate on an integer. 4. Keep interfaces small so that users don’t end up depending on things they don’t need. Agreed the problem is, the definition of an object in OOP usually ties muteable state and logic together. Your average object has a getter and setter which are tied together by external scope, so by definition OOP ties together things that shouldn't belong together. You are not keeping your interfaces small.... by definition it is already too big. If you defined the logic as I said above separating state changes away from combinators you'd have even smaller interfaces. One for changing state. And the other logic is stateless. 5. Dependency inversion principle. I mean yeah. Write your logic in layers. The problem is OOP people only use this principle at the module level. The better way to program is to have all your methods follow the dependency inversion principle. You can't do this if methods are modifying external scope shared by another method. Use combinators and by definition every sector of your program is following this principle not just "modules"