SOLID design principles in C++: Open Closed Principle | Hacker News Reader

SOLID design principles in C++: Open Closed Principle

vishalchovatiya.com

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.

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.

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.

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.

Benefits of Open Closed Principle

- Extensibility: Not true, unless you solve the expression problem either you pay while adding new types, or you pay while adding new functions

- Maintainability: Not true, dressing code in layers of indirection is a recipe for unmaintainable code due to spaghetti control flow

- Flexibility: At one point, you can't shove an accretive development model through the door, it's just too clunky and won't fit.

Also all those patterns that keep being mentioned (Factory ew) just highlight deficiencies in the programming language.

Is it me, or is the recommendation of adding a level of abstraction less readable than the “bad” example using “by_size_and_color?” Additionally, another example of a developer coming in and making it more extensible when that is not the requirement 80% of the time.

Full disclosure, I’m not a professional C++ developer. I haven’t touched the language in 20 years. However, I’ve attempted to keep up with its development since my hobby game development years in my teens.

It's overengineering for sure (or architecture astronauting).

Why not use enums and or bit wise operation to represent filters? Templates, categories and custom operators seem a bit too much to do simple bit logic.

It would seem to make more sense to let the selection functional be a lambda. Neither the original code nor the resulting code are really all that great... It merely exchanges one form of code duplication for another. Nor is the Open Closed Principle in general all that great, as other comments are also noticing.

Reply on news.ycombinator.com