Design Pattern principles (single, open and closed, Rishi replacement, dependency reversal, and the Five Principles of the dimit Law)

For a single responsibility principle, there should be only one reason for its change in a category.

If a class has too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or suppress the class's ability to fulfill other responsibilities. When a change occurs, the design may suffer unexpected damages. In fact, we can find it for classification and separation.

What software design really needs to do is to discover responsibilities and separate them from each other. In fact, it is not difficult to determine whether classes should be separated. That is, if you can think of another motive to change a class, then this class has both responsibilities and responsibilities, separation of duties should be considered.

The open-closed principle means that software entities (classes, modules, functions, and so on) can be expanded but cannot be modified.
These two principles actually have two characteristics: one is "Open for expansion" and the other is "Closed for changes ".

No matter how closed the module is, there will be some changes that cannot be closed to it. Since it is impossible to completely close the module, the designer must make a choice for the change closure of the module designed by him. He must first guess the most likely types of changes, and then construct an abstraction to isolate those changes.

In the face of requirements, changes to the program are made by adding new Code, rather than changing the existing code. This is the spirit of the open-closed principle.

The open and closed principle is the core of object-oriented design. Following this principle can bring about the huge benefits that object-oriented technology claims, that is, maintenance, scalability, reusability, and flexibility. It is also not a good idea for developers to abstract those parts that present frequent changes, and then deliberately abstract each part of the application.

The principle of dependency inversion is that abstraction should not depend on details, and details should depend on abstraction.

To put it bluntly, we need to program the interface instead of programming the interface. For example, no matter whether the computer's motherboard, CPU, memory, or hard disk are designed for the interface, if it is designed for implementation, the memory will correspond to a specific brand of motherboard, then there will be the embarrassment of changing the memory and changing the motherboard.

Therefore, the development of PC computer hardware is similar to the Development of Object-oriented thinking. This also shows that all things in the world follow the rules similar to Zheng. Whoever grasped these rules first became the first strong.

The dependency reversal principle can be said to be a sign of object-oriented design. It is not important to write a program in that language. If the programming is based on abstract programming rather than detailed programming, that is, all dependencies in the program are terminated from abstract classes or interfaces, that is, object-oriented design, and vice versa, that is, procedural design.

The Rys replacement principle, child types must be able to replace their parent types.

Only when the child class can replace the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can also add new behaviors based on the parent class.

For example, Cats inherit from animals and possess behaviors such as eating, drinking, and calling as animals. However, one day, we need to have similar behaviors for cattle and sheep, because they all inherit from animals, so there is no need to change anything except the instantiation of the program.

It is precisely because of the replacement of the Child type that the module that uses the parent class can be extended without modification, so that the principle of openness-closure is possible.

Dimit's Law: If two classes do not need to communicate with each other directly, they should not interact directly. If one class needs to call a method of another class, it can be forwarded by a third party.

In terms of class structure design, each class should minimize the access permissions of members. That is to say, a class encapsulates its own private State, do not disclose fields or behaviors that other classes know.

The fundamental idea of the dimit law is to emphasize the loose coupling between classes. In program design, the weaker the coupling between classes, the more conducive to reuse. A class with weak coupling is modified and will not affect related classes. That is to say, Information Hiding promotes the reuse of software.