5 ms·

I hate the SOLID principles. Especially that they're called principles when they should've been called design patterns at best. In our era of multi-paradigm sof

I hate the SOLID principles. Especially that they're called principles when they should've been called design patterns at best. In our era of multi-paradigm software engineering OOP is nothing but a tool among others for structuring a program. Designing all classes in your software to be "extensible in the future for new business requirements" is such a useless (and in most cases, harmful) goal. The number of classes and interfaces should be kept to a possible minimum. In fact, the number of lines should be kept to a reasonable minimum. Rewriting code is good. Refactoring classes to be more generalized (when it actually is needed) is good. These so-called principles are such newbie traps and they go against the only principle in software engineering, the only law of the land that I recognize: your code should be simple and readable.

diroussel 6y ago
Ah it's good to hear someone say that. I've never really liked SOLID either. I never found them to give any clear useful guidance, just lot's of discussion about what they really mean. Which principles you should stick to should be decided by your team, and based on your context: language, app/library, test approach, budget, etc.
borplk 6y ago
Things like "SOLID principles" are what I call "Dunning–Kruger Traps". They lure the newbie (or worse, beginner experts) with a "learn me and become an expert" bait. They usually don't stand on a substantial merit. They are hyped up by some famous nerd and it perpetuates because every body hears someone talk about it. I can literally make up other legitimate sounding principles on the spot that mean nothing. If you hype it up enough people will start repeating it. Until the little kid notices that the emperor is walking around all naked.
apotheosis 6y ago
Your typical factory pattern is an example of the OCP; move the part that changes into its own class (a factory). The class that uses the factory is closed to changes, but open to extension (new factory types). Perhaps it's not the SOLID principles that are bad, but they way you've seen them used? More important than the principles is how they're interpreted and implemented, I think.

diroussel 6y ago

Ah it's good to hear someone say that. I've never really liked SOLID either. I never found them to give any clear useful guidance, just lot's of discussion about what they really mean. Which principles you should stick to should be decided by your team, and based on your context: language, app/library, test approach, budget, etc.

borplk 6y ago

Things like "SOLID principles" are what I call "Dunning–Kruger Traps". They lure the newbie (or worse, beginner experts) with a "learn me and become an expert" bait. They usually don't stand on a substantial merit. They are hyped up by some famous nerd and it perpetuates because every body hears someone talk about it. I can literally make up other legitimate sounding principles on the spot that mean nothing. If you hype it up enough people will start repeating it. Until the little kid notices that the emperor is walking around all naked.

apotheosis 6y ago

Your typical factory pattern is an example of the OCP; move the part that changes into its own class (a factory). The class that uses the factory is closed to changes, but open to extension (new factory types). Perhaps it's not the SOLID principles that are bad, but they way you've seen them used? More important than the principles is how they're interpreted and implemented, I think.