"Design Patterns" Six Design Principles

The principle of single responsibility

       For a class, there should be only one reason for it to change . If there is more than one motivation to change a class, then the class has more than one responsibility, which needs to be separated.

       For example, if you go to a Chinese restaurant to eat rice bowls (if the whole code is placed in one class), if you suddenly want to change to the snack street to eat rice bowls, you need to change this class. Then when you arrive at the snack street, you suddenly want to eat Mala Tang, then you have to change the category again. At this point, there are already two factors (location, meal) that cause changes in this class, so you need to split your code. It is divided into one location category and one meal category. In this way, if you want to change the place, you can directly modify the location category. If you want to change the meal type, you can modify the meal category.

The open-closed principle

       It means that software entities (classes, modules, functions, etc.) should be extensible, but not modifiable. This principle has two characteristics, one is open for extension and the other is closed for modification. This principle allows us to maintain relative stability in the face of changes in requirements during design, so that the system can continue to introduce new versions after the first version.

       For example, if you want to design a simple calculator, which contains the addition and subtraction algorithm, then you can abstract the two laws, get an abstract operation class, and then have two concrete subclasses (addition class, subtraction class) to inherit the abstract class. In this way, when you expand the algorithm of the calculator again and add the multiplication and division algorithm, you don't have to change the entire code, but directly add two concrete subclasses to integrate the abstract operation class.

       The open-closed principle is at the heart of object-oriented design. Developers should only abstract those parts of the program that show frequent changes, in order to achieve the characteristics of maintainability, extensibility, reusability, and flexibility brought by object-oriented.

 

3. Dependency Inversion Principle

       A. High-level modules should not depend on low-level modules. Both should rely on abstraction . B. Abstraction should not depend on details, and details should depend on abstraction .

       For example, if the CPU, memory, and hard disk in your PC all need to rely on a specific motherboard, once the motherboard is broken, all the components will be useless, which is obviously unreasonable. Conversely, if the memory is damaged, it should not cause other components to be unavailable. If both high-level modules and low-level modules depend on abstraction, the specific point is an interface or an abstract class. As long as the interface is stable, changes to any one do not need to worry about the other being affected, which makes both high-level modules and low-level modules. Easily reused.

       Dependency inversion can actually be said to be a sign of object-oriented design. It doesn't matter which language you use to write the program. If you think about how to program for abstraction rather than for details, all dependencies in the program are terminated. For abstract classes or interfaces, it is object-oriented design, and vice versa, it is procedural design.

 

Fourth, the principle of conversion

       Subtypes must be able to replace their supertypes. In object-oriented design, the subclass has all the non-private behaviors and properties of the superclass. Such as: birds can fly, penguins can't fly, then penguins are birds? Can penguins inherit from the bird class? The answer is no, because birds can fly and penguins can't!

       Because of the Li-style conversion principle, inheritance and reuse become possible. Only when the subclass can replace the parent class and the functions of the software unit are not impressed, the parent class can be truly reused, and the subclass can also be used in the parent class. Add new behaviors based on the class. It is the substitutability of subtypes that allows modules that use supertypes to extend without modification .

 

5. Law of Demeter

   If two classes do not have to communicate directly with each other, then the two classes should not interact directly. If one of the classes needs to call a method of the other class, the call can be forwarded through a third party .

       Classic explanation, observer mode. If the boss comes back, the front desk will tell Xiao Wang directly, and then Xiao Wang will notify Xiao Li who is playing games and Xiao Liu who is trading stocks to turn off the network and start work. In the same way, when a pony chasing an NBA game is added in addition to Xiao Li who plays games and Xiao Liu who trades stocks, Xiao Wang needs to notify one more person, and then indirectly knows from the front desk whether the boss is back. One more person was notified of this specific notification. On this, the notification of whether the boss came back and whether Xiao Li, Xiao Liu, and Xiao Ma shut down the network are not directly related, but communicated layer by layer and made actions.

 

6. Synthesis/aggregation multiplexing

       Try to use composition/aggregation and try not to use class inheritance.

       The point to be understood here is the strength of coupling among the four major UML relationships . The stronger the coupling between the two classes, the greater the range of variation caused when a variation occurs. Inheritance is a kind of "strong coupling" relationship. When the parent class changes, the child class must change accordingly. The relationship is relatively loose. Try to use the synthesis/aggregation relationship as much as possible to reduce the coupling degree to a certain extent. The best example is embodied: bridge mode.

                           <<< Coupling from weak to strong <<<

                Dependency---Association---Aggregation---Composition---Inheritance