Open-Close principle: Software entities (classes, modules, functions, and so on) should be extensible, but not modifiable. is open for extensions and is closed for changes.
The problem: What kind of design can face the change of the demand but maintain relative stability, so that the system can continue to launch a new version after the first version?
No matter how "closed" the module is, there are some changes that cannot be closed, and since it is not possible to completely close the design, the designer must make a choice as to what kind of change the module should be designed for, and he must first guess what kind of change is most likely to occur and then construct an abstraction to isolate those changes.
When we first wrote the code, we assumed that the change would not happen. When changes occur, we create abstractions to isolate similar changes that occur later.
What we want is to know the changes that may occur soon after the development work unfolds. The longer you wait to find out what changes are possible, the more difficult it is to create the correct abstraction.
The open-close principle is the core of object-oriented design. Following this principle leads to the huge benefits claimed by object-oriented technology, which is maintainable, extensible, reusable, and flexible. Developers should abstract only those parts of the program that are frequently changing, however, it is not a good idea to deliberately abstract every part of the application, rejecting the immature abstraction and abstraction itself as important.
"Big Talk design mode": open-closed principle