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?
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 !