Design Mode Study Note 4 [open-closed principle]

Open and closed principle: software entities (classes, modules, functions, and so on) should be extensible, but cannot be modified. In fact, this principle has two features: openness for expansion, and closed for changes. What kind of design will be able to maintain relative stability in the face of demand changes, so that the system can continuously launch new versions after the first version? The open and closed principle gives us the answer. 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 most likely types of changes, and then construct an abstraction to isolate those changes. Take immediate action when changes occur, instead of meeting the current changes, and do not consider other possible changes. In our initial compilation CodeIf the change does not occur. When a change occurs, we create an abstraction to isolate similar changes that occur later. The spirit of openness and closures is: in the face of changes in needs ProgramInstead of changing the existing code. We hope that we will know the possible changes shortly after the development work starts. The longer it takes to identify possible changes, the more difficult it is to create a correct abstraction. The open-closed principle is the core of object-oriented 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 also not a good idea to deliberately abstract each part of the application. Rejecting immature abstractions is just as important as abstraction itself.