Design Pattern 32-six principles of design pattern (6): Open and closed principles

Definition: A software entity, such as a class, module, or function, should be open to extensions and closed to modifications.

Problem:During the software life cycle, errors may be introduced to the Old Code when the original code of the software needs to be modified due to changes, upgrades, maintenance, and other reasons, it may also cause us to have to refactor the entire function and re-test the original code.

Solution:When the software needs to change, try to implement changes by extending the behavior of the software entity, rather than modifying the existing code.

The open/closed principle is the most basic design principle in object-oriented design. It guides us how to establish a stable and flexible system. The principle of opening/closing may be the most vague one defined in the six principles of the design model. It only tells us how to make it open to the extension and disable the modification, but how can we make it open to the extension, we have not explicitly told you to disable the modification. In the past, if someone told me that "you must follow the principle of opening and closing when designing", I would feel that he did not say anything, but it seems that he has said nothing. This is because the principle of open/closed is too weak.

After carefully thinking about and reading many design patterns, I finally got to know the principle of opening/closing. In fact, we follow the five principles above the design pattern and use 23 design patterns to follow the open and closed principles. That is to say, as long as we comply with the preceding five principles, the software designed will naturally comply with the open and closed principles, this open and closed principle is more like the "average score" of the top five principles. The top five principles comply well, and the average score naturally increases. This shows that the software design open and closed principles comply well; if the preceding five principles are not followed properly, it indicates that the principle of opening and closing is not followed well.

In fact, I believe that the principle of opening and closing is nothing more than to express the following meanings:Use abstraction to build a framework and implement extended details.The flexibility and adaptability of abstraction are good. As long as the abstraction is reasonable, the stability of the software architecture can be basically maintained. The details of software changes are extended using abstract-derived implementation classes. When the software needs to change, we only need to re-derive an implementation class to expand as needed. Of course, the premise is that our abstraction should be reasonable, and we must be proactive and predictable about changes in demand.

Here, let's look back at the five principles mentioned above, just to tell usUse abstraction to build a framework and implement extended detailsOnly considerations: the single responsibility principle tells us that the implementation class should have a single responsibility; the lean replacement principle tells us not to undermine the inheritance system; the Dependency inversion principle tells us that we should face interface programming; the interface isolation principle tells us to simplify and simplify the interface design; the Demeter rule tells us to reduce coupling. The principle of opening and closing is the general principle. He told us to open the extension and disable the modification.

Finally, I will explain how to follow these six principles. The adherence to these six principles is not a question of "yes" or "no", but a question of "more" or "less". That is to say, we generally do not mean whether or not we comply with the six principles, but the degree of compliance. Everything is too late. The same is true for the six design principles of the design model. The purpose of formulating these six principles is not to strictly abide by them, but to use them flexibly according to the actual situation. The degree of compliance with them is well designed as long as they are within a reasonable scope. Let's use a picture to illustrate.

Each dimension in the figure represents a principle. We draw a point on the dimension based on the degree of compliance with this principle. If this principle is followed properly, this point should fall inside the red concentric circle; if the difference is observed, it will be inside the small circle; if it is excessively observed, it will fall outside the large circle. A good design is embodied in the figure, and six vertices should be hexagonal in the concentric circle.

In the middle, Design 1 and design 2 are good designs, and their degree of compliance with the six principles is within a reasonable range; Design 3 and design 4 although there are some deficiencies, but it is also basically acceptable. Design 5 is a serious deficiency and does not comply with the principles well. Design 6 follows the transition, design 5 and Design 6 are designs that urgently need reconstruction.

By now, the six principles of the design model have been completed. The main reference books include "design patterns", "Zen of design patterns", "big talk Design Patterns", and some scattered articles on the Internet, however, the main content is my understanding of these six principles. The purpose of writing this article is to systematically organize these six principles, and share it with the majority of users, because the design mode is indeed very important for programmers. Just as there is a saying that one thousand of the one thousand readers have Hamlet in their eyes. If you have different understandings of these six principles, please leave a message and discuss them together.

Below is a link to the previous five design principles

1. Single Responsibility Principle)

2. liskov substitution principle)

3. Dependency inversion principle (dependence inversion principle)

4. Interface segregation principle)

5. Law of Demeter)

For the convenience of favorites, the download of the Word version is given below.

From: http://blog.csdn.net/zhengzhb