written by owen on 2015-Jun-23.

SOLID OOP is kinda strange, if not nonsensical. I see the articles copy pasted all over the internet and I could not exactly wrap my head around why such articles would even need to exist. It is as if everybody doing OOP is writing utter non-sense and the OOP authorities are trying to find a way to reel these people back in line by coming up with a formula for not writing bat shit crazy OOP. Either way let me rant about each of these letters a little;

Single responsibility principle
a class should have only a single responsibility (i.e. only one potential change in the software’s specification should be able to affect the specification of the class)

Open/closed principle
“software entities … should be open for extension, but closed for modification.”Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”[8]

Dependency inversion principle
one should “Depend upon Abstractions. Do not depend upon concretions.”[8]
Dependency injection is one method of following this principle.

source: www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

S - Single responsibility principle (SRP)

This basically goes against everything that makes programming work. Programming is about designing a system to solve a problem. Programming is not about fragmenting and coding a millions of little class pieces so they can be hung up like Christmas lights. Fragmenting you code does not make it more maintainable or easier to read - it makes it fragmented. Programmers code in order to solve problems in as short a time as possible. Loops, variables, arrays, structs, classes, conditional statements. Programmers are not novelists. Leave the Harry Porter series to the kids. If you want to spend your time writing 20 classes to "simulate" a switch conditional statement then by all means go ahead. Programs change, it is what they do, but fragmenting everything into tiny bits is not doing to help make it more maintainable or make anyone reuse your bloated class soup. Eventually even you will get tired of your own classes. Use the switch statement. The reason why people are confused about what they should put in a class is because you are all misusing classes as flow a control system.

O - Open/closed principle (OCP)

See now if you are writing your own program OR you are a part of a team who do not want to change the original class structure because the million-line house-of-cards they built will fall down, then all I can say is LOL. Even so if the class had a single responsibility then why would you even want to extend it? just leave it alone! Something changed? oh no! Lets extend the bullshit that we started some more until one day we give up and refactor it all. Why? Because a new version came out. "Everything we designed was crap and short sited" . Tools to the rescue. This is the contention I have with all this; sometimes its fine to extend, other times you make everything private. Everybody is working on live source that compiles/run as single working program and you are worried about changing superclasses? what are you writing a DLL for windows? Are you the Laravel lead programer? A DLL has external dependences. Even the great big facebook breaks APIs willy-nilly to protect its own interests. If you have no external dependences why are you afraid to change your superclasses to make the entire program better?

L - Liskov substitution principle (LSP)

This is some kind of inheritance or polymorphism right? Isn't that automatic with the pointers all being of the same superclass type? Are you all passing around sub-classes that do not inherit the properties of the superclass? oh LOL. Is this even possible? Refactoring will solve any problem of misusing class syntax to represent control flow. lol. No matter how confusing you are writing your classes there will always be an order of execution. Lets create some leaky abstractions so its easier to test everything.

I - Interface segregation principle (ISP)

Oh so the Liskov principle doesn't really apply here right? suppose I don't have any interfaces? should I make some interfaces for myself and eat my own dog food? Maybe I should build a framework for myself to use so that I can encapsulate the program from myself. Seems like I'm spending time modeling instead of solving problems. I don't know sounds like I am wasting my own time writing interfaces for my calculator program exe. Are all OOP programmers writing mini APIs for themselves? Writing APIs on top of a API for client APIs to consume? The interface is a API to the business logic API which is written on a framework API that is on top of language? No wonder it takes so long to code anything nowadays. And it takes even longer to update this code once its been written - IF IT EVER GETS FINISHED.

D - Dependency inversion principle (DIP)

I don;t even know what this means. High level objects, low level objects? All swimming around in memory. What if I only have objects all on the same level? They all have a single responsibility and the same function/methods. All one big object soup. what do I do then? This has something to do with TDD, I'm pretty sure. In the future we won't need to write good programs, the tests will tell us if the program is perfect or not lol. Write more tests!

Conclusion

SOLID seems to be a catch all, with no particular solution to anything. If SOLID was as useful as proponents state then you could essentially autogenerate the code you need from a few basic bits of data such as table definitions and nouns. Why do you even need to program anything at all if there is the magical way to do it?

However SOLID as with other attempts at standardizing OOP code has no room for intelligent thought and creative concepts. SOLID is basically saying that if you write your bad OOP program "this way" it won't suck and any problem you set out to solve will magically be solved and maintainable. But such is not the case in the real world. In the real world you have a million problems, projects that run many years over due, OOP frameworks that keep the same name but change API every version and programs that never finish because they waste all their time building interfaces that they refactor every six months.

You've spent all this time training OOP programmers to MVC only to be telling them now that they are doing it wrong? Maybe they should have learnt how to think and conceptualize a program in terms of maintainability, proper syntax and resource management before you threw them into a pot of API call soup and left them in there to fend for themselves.

It always seems like the OOP community is playing catchup, monkey patching itself as it goes along; Java, SOAP, XML, json, listeners, contracts, singletons, interfaces, delegates, autoloader, just-in-time instantiation, dependency injection, lazy listeners, pub-sub, promises. I guess someone realized that you cannot load up a million objects in memory at the same time just so you can have a little OOP pool party. News flash the RDMS is a singleton, a global variable struct, I'm sorry, set up a test database or soemthing.

New words are invented everyday to fix some deficiency or experiment gone wrong. Millions of dollars spent on code once said to be maintainable gets thrown out the window. It is all the same thing; one guy at the top says he has the solution to the OOP problem and everybody follows, one lead programmer, design by committee - github open source plugins. SOLID is just another solution to the problem of bad OOP programmers and it is not even a good solution because it does not address the root problem of bad OOP. Tools to the rescue. What we need are ROBOT - not tools, and certainly not more OOP programmers writing SOLID code.

[q]When it comes to the everyday work of software development, it seems that most developers either don’t understand how to get to these principles or don’t think it’s possible in a reasonable time frame. However, these principles are not just for the academics. Developers should apply them to their development efforts. The question should change from “Can you apply the principles, here?” to “How do you correctly apply the principles, here? link [/q]

Who is this speaking? is it an academic? is he a developer? I am guessing this person is a novelist! Why is he telling developers what to do? This person thinks that this will solve the big problem. Maybe he thinks programmers sit down and write APIs all day , APIs for frameworks, APIs for APIs, APIs for junior programmers. Then what do the junior programmers do? They use the verbose APIs that are passed down to them and they wrap those in APIs that they write for themselves. And it goes around and around in a great song and dance until new requirements are released and the whole structure is refactored. All that time wasted building a SOLID tightly coupled house of cards. The only solution is robots. Good luck for the next batch of noobs.

permanent link. Find similar posts in Articles.