General principles in Design Patterns

 

General principles in Design Patterns

I. "open-closed" principle (OCP) The principle of open-closed principle is that a software entity should be open to extensions and closed to modifications. Advantages: New behaviors can be provided by extending existing software systems. The existing software modules, especially the most important abstraction layer modules, cannot be modified, which makes the software system in change stable and continuous. Example: One Country, Two Systems To achieve the reunification of the motherland, Deng Xiaoping proposed the idea of "One Country, Two Systems", which is a good principle of "Opening and Closing ". "One Country" is closed, that is, adhering to the premise of one China. This cannot be changed. In the words of the central government, "Everything can be discussed under the premise of one China ". "Two Systems" means opening up. You are on your path to capitalism and I am on my path to socialism. "One Country, Two Systems" cannot change the existing one-China order, and include the capitalist system in the existing political system, thus expanding this order. In an object-oriented language, the abstraction layer of the system is not allowed to be changed, but the Implementation Layer of the system is allowed to be changed. II, Lee's replacement principle (LSP) Liskov substitution principle (Rishi replacement principle): Subtypes must be able to replace their base types. In turn, replacement is not valid. If there is a "student" class with two Derived classes: "boys" and "girls", there is a "friend" method in the "boys" class, the received parameter is "student", so I can pass a "boy" instance to the method "find friends", so that the subclass can replace the base type. In turn, if the boys' class has another method of "finding a girlfriend", the parameters received can only be of the "girl" type, it is wrong if you pass in an object of the "student" class. III, Dependency inversion principle(DIP) Dependence inversion principle: It depends on abstraction and not on specifics. Abstraction should not depend on details; details should depend on abstraction; interface programming rather than implementation programming. The dependency relationships created by traditional procedural programming are dependent on details, which is poor because the policies are affected by changes in details. The dependency inversion principle makes the details and policies depend on abstraction. The stability of abstraction determines the stability of the system. For example, I have an "employee" class, which contains a "work evaluation" method to return the assessment results. You can write your own code in this method, employees are assessed (70% + 10% + 20% + + + ). However, it is easy for you to find out the problems. The code for this assessment can only be used to assess middle-level leaders. It is not suitable for the assessment of top-level leaders and employees at the lowest level. At this time, we will think of classifying employees and setting up different classes (high-level, middle-level, and employee-level) for different types of employees. The code for the "work assessment" method is also different. OK. Congratulations, you have taken another step. However, there is another question in front of you. If there is a "report" class with a "print" method, this method is used to print the results of each employee's work assessment, then, the parameters in the "print" method should receive the "employee" class, and then call the "employee" class "work evaluation" method to obtain the employee's assessment results and print them. Now the problem arises: there are many different types of employee classes. Which type of employee should I receive in the print method? Some may think that it is unwise to create different "print" methods for different types of employees. Why? Because your head is still bound to detail-oriented programming, and you have not extended programming for interfaces into your mind. Solution: create an "employee" interface, one of which is an abstract method "work assessment". On this interface, implement three categories: "senior", "Middle", and "employee, the parameters in the "print" method of the "Report" class only need to receive parameters of the "employee" interface type. Isn't that all done? In addition, when the interface remains unchanged, you can add a new derived class without affecting the implementation of the "Report" class. IV, Interface isolation principle (ISP) Interface segregation principle: it is better to use multiple special interfaces than to use a single total interface. In other words, from the perspective of a customer class: the dependence of a class on another class should be based on the minimum interface. An interface that is too bloated is a pollution to the interface. Customers should not be forced to rely on methods they do not need. For example, the 10-week return to Hong Kong is approaching. Suppose we need two floats ". If you create two floats named "brilliant ten years" and "oriental changge", what will you do? Of course, some people will want to create a "floats" interface, and then use the "brilliant ten years" and "oriental changge" floats class to implement it, derive it, And then instantiate it. OK. congratulations first, because you know you want to program the interface. But we all know that floats should not be too similar. It is best to be unconventional, right? Let's take a look at the just-designed "floats" interface, isn't it a little too "domineering? In other words, this interface will lead to two floats "exactly the same", but does not reflect their own characteristics. How can this problem be solved? The answer is: interface breaking. Create three interfaces: movable, festive, and novel. The classes of the two floats implement these three interfaces respectively. Now you don't have to worry about two similar floats.   V. Merging and reuse principles (CRP) The Composite Reuse Principle or CRP principle is to use existing objects in a new object to make them part of the new object; new objects reuse existing functions by assigning them. I think it's easy for everyone to understand this. What do you do if you want to build a computer? A lot of friends will do DIY, buy CPU, memory, hard disk, motherboard, display and other components inserted together on OK. Should no one be stupid enough to build your own computer components on a board? Here you need to understand a question: "has... "And" is... " "Is... "Is strictly defined in the classification sense, meaning that one class is another class" one ". "Has... "It indicates that a role has a certain responsibility. A common cause of incorrect use inheritance rather than merging/aggregation is that the "has... "As" is... ". VI, Dimit law (Levels) The law of Demeter (or the short-cut level of measure) is also called the least knowledge principle (least knowledge principle or LKP). That is to say, an object should have as little knowledge as possible about other objects. Only communicate with your friends directly. Do not talk to strangers. Lao Tzu cloud: "little country, few people ...... Neighboring countries look at each other and hear each other from each other ." Isolate the ruled objects so that they do not have direct communication, which can achieve the effect of splitting and then divide and conquer them separately. The dimit rule coincides with Lao Tzu's "little country and few people" rule. (CHE Yanlu)