Definition: software entities such as classes, modules, and functions should be open for extension and closed for modification.
Cause of the problem: During the software life cycle, when the original code needs to be modified due to changes, upgrades and maintenance, errors may be introduced into the old code, or we may have to reconstruct the whole function, and the original code needs to be re-tested.
Solution: When software needs to change, try to do so by extending the behavior of software entities rather than by modifying existing code.
Open and close principle is the most basic design principle in object-oriented design, it guides us how to establish stable and flexible system. The open and closed principle is probably the most ill-defined of the six principles of design pattern. It only tells us to open for extension and close for modification, but it doesn’t tell us exactly how to open for extension and close for modification. In the past, if someone told me, “You have to follow the open and close principle when you design,” I would think he didn’t say anything, but he seemed to say everything. Because the open close principle is really too weak.
After careful thinking and reading many design pattern articles, I finally have a little understanding of the on/off principle. In fact, we follow the first five principles of design patterns, and the purpose of using 23 design patterns is to follow the open closed principle. That is to say, as long as we comply with the first five principles well, the designed software is naturally in line with the open and closed principle, which is more like the “average score” of the first five principles. If the first five principles are well complied with, the average score will be naturally high, indicating that the software design complies with the open and closed principle well. If the first five principles are not well observed, then the open and close principle is not well observed.
In fact, I think that the open closed principle is nothing more than to express such a layer of meaning: use abstraction to build the framework, use implementation to expand the details. Because abstraction has good flexibility and wide adaptability, as long as abstraction is reasonable, it can basically maintain the stability of software architecture. And the changeable details in the software, we use the implementation class derived from the abstract to carry on the extension, when the software needs to change, we only need to derive an implementation class to expand according to the requirements. The premise, of course, is that our abstractions should be reasonable, forward-looking and predictive of changes in requirements.
At this point, think back to the five principles that tell us to build frameworks with abstractions and extend details with implementations: the single responsibility principle tells us to implement classes with a single responsibility; Richter’s substitution tells us not to break the inheritance system; The dependency inversion principle tells us to program for interfaces; The principle of interface isolation tells us to keep interfaces simple and simple when designing them. Demeter’s rule tells us to reduce coupling. And the open closed principle is the general principle, he told us to be open to expansion, closed to modification.
Finally, explain how to follow these six principles. Adherence to these six principles is not a matter of yes or no, but of more or less, that is, we generally do not say whether there is compliance, but how much compliance. Everything is too much of a good thing, and so are the six design principles of design patterns. The purpose of these six principles is not to follow them rigidly, but to apply them flexibly. Compliance with them is good design as long as it is within a reasonable range. Let’s use a picture to illustrate.
Each dimension in the figure represents a principle. We draw a point on the dimension according to the degree of compliance with this principle. If the principle is properly observed, this point should fall inside the red concentric circle. If the difference is observed, the point will be inside the small circle; If you overobey, the point will fall outside the circle. A good design in a diagram would be a hexagon with six vertices in concentric circles.
In the figure above, Design 1 and 2 are good designs, and their compliance with the six principles is within a reasonable range. Design 3, Design 4 Although the design has some shortcomings, it is basically acceptable; Design 5 is seriously inadequate and does not follow the principles well. Design 6 follows the transition, and Design 5 and Design 6 are both desperately in need of refactoring.
This concludes the six principles of design patterns. The main reference books are “Design Pattern”, “Zen of Design Pattern”, “Big Talk Design Pattern” and some scattered articles on the Internet, but the main content is mainly my perception of these six principles. The purpose of this article is on the one hand to systematically organize these six principles, on the other hand to share with the majority of netizens, because design patterns are really very important to programmers. As the saying goes, there are a thousand Hamlets in the eyes of a thousand readers. If you have a different understanding of these six principles from me, please leave a comment and discuss them together.