Some of the SOLID principles are quite easy to understand and their benefits are quite explanatory: The Single responsibility principles, for example, has an obvious one. Software entities do only one thing each. It becomes really easy to know what a bit of code does, even in the middle of a huge application, because it does one thing.
On the other hand, the Open/Closed principle is a bit more abstract.
While suggesting to my boss that we could implement some pattern at some place in our app, I proudly said that this would be more respectful to the Open/Closed principle, thus better.
He asked why «adding classes» would be better than «editing method», since we would still be making changes; and that adding classes would make our app grow faster, which would then make it maybe even less maintainable.
To be honest, I was not expecting that. And I realized I could justify interests of most programming principles I know, but not «adding classes» over «changing method», as both were «adding code» in a way.
How would you describe benefits of trying to apply the Open/Closed principle ? Do you think I misunderstood it?
In general, except «it's more maintainable so we will avoid expenses in the long run», what are your justifications when it comes to implementing some pattern / anything related to programming principles (especially to tech pairs / mostly if it's a lead/CTO/anyone tech and higher than you in your company hierarchy) ?
Top comments (2)
The Open-Closed principle says that modules should be open for extension but closed for modification. That means you should be able to extend the behavior of a module without modifying it. Or, to say this another way, you should be able to add new behaviors by adding new code, not changing old code.
When you change old code, you risk introducing bugs in existing behaviors. You also complicate the design of the old code to accommodate the new behaviors. You also must redeploy the old code ever time a new behavior is added.
When you conform to the OCP you do not risk introducing bugs into old code. You do not complicate the design of the old code. And you do not have to redeploy the old code. That old code can sit in Jar files or DLLs or Gems, or whatever module format you use, unaltered.
This facilitates a plugin structure. New features are plugins to the existing application. They can be deployed independently. They can be deployed optionally. And, best of all, they can be developed independently.
So it’s not just a matter of adding classes vs. changing a method. Rather it’s a matter of organizing the code such that behaviors are isolated, independently deployable, independently developable, and optional. Who wouldn’t want that?
This is what I feel was missing in my understanding. It's much clearer now !
Thank you for this great explanation !