Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.
It is open for expansion and closed for change.
No matter how close the module is, there will be some changes that cannot be closed to it. Since it cannot be completely closed, the designer must choose which change should be closed for the module he designed. He must first guess the types most likely to change, and then construct an abstraction to isolate those changes.
In our initial code, we assume that changes do not occur. When changes occur, we create abstractions to isolate similar changes that will occur later.
In the face of requirements, changes to the program are made by adding new Code, rather than changing the existing code. This is the spirit of the development-closed principle.
Development-closed principle is the core of object-oriented programming design. Following this principle can bring about the huge benefits that object-oriented technology claims, that is, maintenance, scalability, reusability, and flexibility. Developers should only abstract those parts that present frequent changes in the program. However, it is not a good idea to abstract all the parts in the program. Rejecting immature abstractions is just as important as abstraction itself.
Chapter 2 Development-closed principles
