Seven Principles of Design Patterns

 

Single Responsibility Principle:

"Single responsibility principle (Single responsibility principle), which means that the function should be single? It can be understood simply, and its accurate explanation is: For a class, there should only be one reason for it to change. We are programming. When it is time, it is natural to give a class various functions. For example, when we write a form application, we usually produce a class such as form, so we put all kinds of codes and think about business operations. Data access sql statements are all written in such a class, which means that no matter what needs come, you have to change this form class, which is actually very bad, troublesome maintenance, impossible to reuse, and also It's anti-flexibility."

 

Single Responsibility Principle (SRP), for a class, there should be only one reason for it to change.

 

"If a class has too many responsibilities, it's tantamount to coupling those responsibilities together, and a change in one responsibility may weaken or inhibit the class's ability to perform other responsibilities. This coupling can lead to brittle designs, and when changes occur, Design suffers unexpected disruptions.”

Open closed principle:

"Open Closed Principle (OCP): It says that software entities (classes, modules, functions, etc.) should be extendable, but not modified."

 

This principle actually has two characteristics , one is "open for extension" and the other is "closed for change" .

"When we are working on any system, we cannot expect that the system will never change once its requirements are determined at the beginning. This is unrealistic. Since the requirements will definitely change, how to deal with the changes, the designed software can be modified relatively easily. As for the new requirements, the whole program will be overturned and restarted. How can the design remain relatively stable in the face of changes in requirements, so that the system can continuously introduce new versions after the first version?"

 

The best way to design software to be easy to maintain and not to cause problems is to expand more and modify less. The meaning of open and closed atoms means that when designing, we must always consider it, try to make this class good enough, and do not modify it after writing. If new requirements come, we can add some classes. The original code can not be changed. I don't know how to move . But no matter how closed, there will be some changes that cannot be closed. Since complete closure is not possible, the designer must make a choice as to which variation of the module he designs should be closed to. He must first guess the most likely kinds of changes, and then construct abstractions to isolate those changes. But changes are difficult to predict, but when small changes occur, we can think of ways to deal with the possibility of larger changes as soon as possible. That is, wait until the change occurs and act immediately.

When we originally wrote the code, it was assumed that changes would not happen. When changes occur, we create abstractions to isolate future changes of the same type. Changes to the program in the face of demand are made by adding new code, not changing existing code. This is the spirit of the open-closed principle.

 

The open-closed principle is at the heart of object-orientation . Following this principle can bring great benefits of object-oriented technology, maintainability, extensibility, reusability, flexibility. Developers should abstract those parts of the program that exhibit frequent changes, however, it is also not a good idea to abstract every part of the program deliberately. Rejecting premature abstraction is as important as the abstraction itself.

Dependency Inversion Principle:

This section first introduces a principle of computer manufacturing through the example of Xiaocai repairing a computer for sister paper: internal sealing, clear interface, and unified standards. Specifically, the specific implementation and manufacture of each component are different, but they all follow an interface standard, so that each component can be seamlessly linked; at the same time, limited extensions can be made on this interface. The relationship between computer accessories also reflects another basic principle: strong cohesion and loose coupling.

Computer accessories also embody the two principles mentioned above, the single responsibility principle and the open and closed principle. A new principle is emphasized here, called Dependence Inversion Principle (DIP). Dependency inversion principle, the original explanation is that abstraction should not depend on details, and details should depend on leisure. To put it bluntly, it is to program for the interface, not for the implementation. Going back to the example, the motherboard, cpu, etc. are all designed for the interface. If it is designed for the implementation, the memory must correspond to a specific brand of motherboard, and there will be embarrassment that the motherboard needs to be replaced when changing the memory.

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. Details should depend on abstraction.

Why is Dependency Inversion needed? In object-oriented development, in order to make common codes reusable, many function libraries are usually written out of these codes, and these underlying functions can be called in new projects. Such as database access module and so on. The problem is also here, when there is a new project, it is found that the high-level modules of the business logic are the same, but the client wants to use a different database or way of storing information. We hope to use these high-level modules again, but the high-level modules are bound to the low-level modules, and these high-level modules cannot be reused, which is troublesome. And if no matter the high-level or low-level modules, they all depend on abstraction, the specific point is an excuse or an abstract class, as long as the excuse is stable, then the changes of any one do not have to worry about being affected by the other. This allows both high-level and low-level modules to be easily reused.

But why rely on abstract interfaces or abstract classes, not afraid of changes? Here we need to talk about the Liskov substitution principle. Specifically, if a software entity uses a parent class, it must be applicable to its subclass, and the difference between the parent class and the subclass object cannot be detected. That is to say, in the software, the parent class is replaced by its subclass, and the behavior of the program does not change. Simply put, subtypes must be able to replace their supertypes. Why is this necessary? Only when the subclass can replace the parent class and the function of the software unit is not affected, the parent class can be truly reused, and the subclass can also add new behaviors on the basis of the parent class.

An example is given in the book. The cat inherits the animal class, and has the behavior of eating, drinking, running, and barking as an animal. When one day, we need dogs, cows, and sheep to have similar behaviors. Since they are all inherited and animals, other than changing the instantiation, the program does not need to be changed.

 

 

Looking back at the dependency inversion principle, high-level modules should not depend on low-level modules, both should depend on abstraction, as shown below:

 

Liskov Substitution Principle:

Liskov Substitution Principle (LSP): Subclasses must be able to replace their supertypes . The supertype here can also refer to an interface. This principle is actually a complement to the open-closed principle. Because the core of the open-closed principle is abstraction, and the Liskov substitution principle is the specification of abstraction.

 

If a software entity uses a parent class, it must be applicable to its subclass, and it cannot detect the difference between the parent class object and the subclass object, that is, in the software, replace the parent class with it The behavior of the program does not change, in short, the subtypes must be able to replace their supertypes . It is precisely because of this principle that inheritance and reuse become possible. Only when the subclass can replace the parent class and the function of the software unit is not affected, the parent class can be truly reused, and the subclass can also be used in the parent class. Add new behavior on top of class.

 

For example, cats are inherited from animals, and they have behaviors such as eating, drinking, running, and barking as animals. But one day, we need dogs, cows, and sheep to have similar behaviors, because they are all inherited from animals. , so there is no need to modify the rest of the program except where the instantiation is changed. It is only with the Liskov substitution principle that the open-closed becomes possible. Modules that use parent types can be extended without modification due to subtype substitutability.

Demeter's Law:

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.

1. The premise emphasized by the Law of Demeter is that in the structural design of the class, each class should minimize the access rights of members, that is to say, a class wraps its own private state without letting other classes know about it. Do not expose fields or behaviors.
2. The weaker the coupling between classes, the more conducive to reuse. If a class in weak coupling is modified, it will not affect related classes. That is, the hiding of information promotes the reuse of software.