The "open-closed" principle of Object-Oriented Software Design

1. What is the open/closed principle?
The "Open-Close" principle means that software entities should be open to scalability and closed to modifications. That is, the software entity should be extended without modification. This principle actually sets a goal for the software design. We know that software design should fully consider the maintainability of the software, that is, when the demand changes, the software structure can flexibly adapt to this change. The "Open-Close" principle provides a basis for evaluating Software maintainability. In fact, the application of the design pattern is to make the software structure meet the "open-close" principle to some extent.

2. Implementation of the "open-close" Principle
The "open-closed" principle provides a goal for the design, but does not clearly provide the implementation means. The following describes how to implement the "open-closed" principle in the object-oriented design.
(1) interface-Oriented Programming
Interface-oriented programming has the following advantages:
A. Reduce coupling between various parts of the program and make it possible to swap program modules. In this way, you do not need to know the type of the object you are using, as long as the object has the interface that the customer expects. In addition, you do not need to know how the object is implemented, as long as you know the abstract class that defines the interface.
B. Facilitate unit testing for each part of the software. By compiling a simulation class (Mock) consistent with the interface, it is easy to implement unit testing for each part of the software. This improves the software reliability and reduces the error rate.
C. The call has been made to implement software modules. During software upgrade, only the changed parts can be deployed without affecting other parts.
For the design mode, the creation mode is the inevitable result of interface-oriented programming. Interface-oriented programming requires that customers who use objects do not understand the specific types of objects, the customer can only instantiate an object through an object that is in charge of instantiating an object, which we call as a "Factory", while the factory object is instantiated in a centralized module during application initialization.

3. encapsulation changes
Any part of the program that may change can be encapsulated as an object, including commands, events, attributes, algorithms, and States. Encapsulation changes are an important means to realize the "open-close" principle and an important way to discover objects in design. Therefore, when analyzing requirements, you must pay attention to what remains unchanged, what changes may occur, and the impact of these changes on encapsulation.
For example, if the behavior of an object remains unchanged, these behaviors can be used as object methods; otherwise, you must consider whether to abstract and encapsulate these behaviors. Another example is that the status can be expressed by the status parameter, for example, temperature and pressure. Status parameters can be used as independent attributes, but it is necessary to abstract them if they are correlated.
In short, encapsulate the parts that may change and take possible changes as objects. In object-oriented design, objects refer not only to objects that exist in reality or visible objects, but also to objects that may change.

4. Replace inheritance with combinations
Inheritance is one of the characteristics of the object-oriented system. Without inheritance, many object-oriented designs will not be discussed. In the design mode, no mode does not involve inheritance. Combination substitution inheritance is not suitable for any situation. In fact, without inheritance, many combinations cannot be implemented at all, and inheritance involving the basic structure cannot be replaced.
Combination and inheritance for the reuse of modules, when the function needs to be extended, it is relatively simple and intuitive to implement reuse using inheritance. You only need to derive a class and add new features to this class to reuse existing classes. However, class inheritance is defined during compilation and cannot be changed during runtime. In addition, inheritance exposes the implementation details of the parent class to the Child class, which destroys encapsulation and makes the Child class highly coupled with the parent class. If the parent class changes, the Child class also changes. If the inherited implementation cannot solve the new problem, you need to modify the parent class. This dependency limits flexibility.
If we want to extend the function by adding subclass, this may happen.

If you don't modify the class and just rely on adding subclass extension, although it seems to meet the "open-close" principle, the results become very ridiculous. One way to replace this scheme is to combine objects and abstract human behaviors into classes ,.

By combining with behavior objects, you can expand the "person" behavior. By adding a new behavior class, the class hierarchy is not added.
Object combination is implemented by obtaining references to other objects at runtime, and the combination requires that objects comply with each other's interface conventions. As long as this Convention is met, an object can dynamically combine different objects during the runtime to achieve reuse. During the design, each part only needs to focus on the Interface conventions, so you do not have to consider the specific implementation. Therefore, the object combination has the minimum coupling and is more flexible, and a large amount of object combinations are used in the design mode.
Again, inheritance is one of the cornerstones of object-oriented development. Replacing successors with combinations is necessary for reuse. Not all inheritance can be replaced with combinations. In addition, there is no inheritance, and there is no way to talk about combinations. In the above example, the behavior subclass still needs to be added to the behavior extension.