It looks to me like Bob Martin needed something starting with O to make SOLID and found in some old book this (possibly useless) Open/Closed principle.
How can Open/Closed co-exists with the Single Responsibility, that states a class should have a single reason for change?
If I want to follow Open/Closed in a long living system, am I supposed to have a chain of dozens/hundreds classes, each extending the previous?
The Open/closed principle implies that you can create systems in which new features are added by adding new code as opposed to changing old code. In order to be perfectly conform to the open/closed principle one must have perfect foresight. For in order to create a system that is fully open to extension and closed to all modification one must be able to perfectly predict the future. One must know in advance what new features the customer will request in order to put extension points to the code.
Having said that we could develop systems that conform well enough to the open/closed principle. By using an iterative process with lots of feedback and refactoring we can improve the parts of the system that change most often by making them open to extension and closed to modification.
As Bob Martin says in one of his lectures: "We cannot completely conform to the open/closed principle. It doesn't mean we should simply give up on the open/closed principle entirely. It may be difficult to make the entire systems to conform to the open/closed principle but it's not difficult to make functions or classes or smaller components to conform to the open/closed principle"
I also came here wondering about the whole "Closed for Modification" bit but I've come to a conclusion that I feel is best demonstrated with an example:
public class FixedSizeCache {
private int maxCacheSize = 8192;
public FixedSizeCache() {
// ...
}
// ...
}
The above example doesn't violate the Single Responsibility Principle but it violates the Open/Closed Principle in a fairly obvious way: whenever you need a FixedSizeCache of a different fixed size you would need to modify the source of the class.
In other words, we should strive to write code that doesn't violate the Open/Closed Principle in obvious ways but this doesn't mean we need to write code that is utterly locked in stone never to be modified (because business requirements change and that should be reflected in our code).
But if the same business requirement changes 7 times and you need to modify your code 7 times, you're probably violating the Open/Closed Principle and are due for a refactoring.
Beautifully formulated question!
If I want to follow Open/Closed in a long living system, am I supposed to have a chain of dozens/hundreds classes, each extending the previous?
This is exaclty what I observed some time ago on a "long living system"; dozens of classes extending by small bits the superclasses. On the other hand modern construction of python goes exactly egainst this principle, and I had the feeling the violation of Open/Closed of modern python was the root cause for the usefullnes and simplicity of many of python's libraries. So I checked SO, and found your question. Well formulated!
