The thing that bothers me about SOLID principles is that they don't come with caveats explaining WHEN it's a good idea to use them.
Single Responsibility Principle: in your example, the Order class only has 4 methods and they're all related. There's no reason to break it up. Breaking it up would just make the code needlessly complex. Blinding following SOLID makes the code worse, not better.
Open-Closed Principle: in your example, the problem isn't that AreaCalculator is open to modification, the problem is that it should use a Shape interface and each Shape should compute its own area. That has nothing to do with Open-Closed. Open-Closed is actually a terrible idea to follow 90% of the time. You shouldn't avoid modifying code. Adding a new subclass every time you need new behavior just adds needless complexity. Blinding following SOLID makes the code worse, not better.
Liskov Substitution Principle: this is fine
Interface Segregation Principle: this is fine
Dependency Inversion Principle: also can be easily overused. Often there's nothing wrong with a low-level module that other modules depend on. When these are big modules that are part of a software system, then sure, it's good advice. But most projects depend on lots of modules that have a single clear purpose and are relatively stable. There's no need to add additional layers of abstraction for these.
For 3/5 of the principles, the principle says "do this", when in reality, most of the time you shouldn't do that. Only when your program is getting complex and hard to maintain does that principle suddenly help give you a solution.
Add comment