Design Mode-open and closed Principle

Recently, we have seen the shadows of design patterns in many occasions. We have been investing in algorithms and data structures for a long time. It is very important to find the design patterns. Sometimes code maintenance, reuse, and scalability are better than pure algorithms. So I picked up Daniel's book "big talk Design Patterns" and referred to the blogs of various big cows on the Internet to start my design patterns journey.

Today, we will introduce the open and closed mode.

Concept:

Software entities (classes, functions, interfaces, etc.) can be extended, but cannot be modified.

Explanation:Openness refers to scalability, and closures refer to non-modifiable features. When designing an architecture design class, consider the functions that this class may need to complete and the functions to be added in the future. After writing these functions, they will not be modified. If the demand changes, you only need to add and derive other subclasses. The original code can not be modified at all, but it is often impossible. No matter how the module is closed, there will be some changes that cannot be closed with it. Since it is impossible to be completely changed and closed, the designer must make a choice on which changes should the module be designed. He must first abstract the types of changes. Then construct an abstract class to isolate those changes. Assume that there is an addition class that can complete all current functions, but the addition class must be modified when Subtraction is required. This violates the principle of open and closed, you can design an abstract operation class as much as possible, and then the addition and subtraction classes inherit the abstract operation class to avoid modifying the addition. Again, we emphasize that the service can be expanded, but cannot be modified. Alternatively, openness refers to scalability and closed refers to non-modification.