Six principles of the design model in one sentence

Principle. Therefore, the name "alias" is the essential meaning. The so-called "one thief first and one king" means that we must first understand the design principles when studying design patterns. All models are developed on the basis of these principles. Some are focused on one, while others are involved. After reading the design pattern, I felt that each pattern had the shadows of these principles, and penetrated the three attributes of object-oriented, and also felt that these principles had similarities ,, they make us Code Workers are converted into artists. Next, let's take a look at the six principles. I hope you can make a picture:

1. Single Responsibility Principle (SRP)
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 together. A change in responsibilities may weaken or the class will always be able to fulfill other responsibilities. This coupling will lead to a fragile design. When a change occurs, the design will suffer unexpected damages. What software design really needs to do is to discover responsibilities and separate them from each other.

One-sentence comment: the excellent embodiment of High Cohesion and low coupling. Don't pull relationships in disorder. It's good to be alone.

2. The open-closed principle (OCP)
The open-closed principle means that software entities (classes, modules, functions, and so on) can be expanded but cannot be modified. That is, the extension is open and the change is closed. It is impossible for us to be an unknown crowdsourced Security Testing. We should try to make a class good enough during design, so we should not modify it if it is well designed. If it cannot be completely closed, when it changes, we will create an abstraction to isolate future similar changes.

One-sentence comment: open expansion, closed changes, and the degree of opening and closing is an art.

3. Dependence inversion principle)
The dependency inversion principle means that the high-level module should not depend on the lower-level module, and both should depend on abstraction. abstraction should not depend on details, and details should depend on abstraction. To put it bluntly, it is necessary to program the interface rather than implement programming. For example, in computer hardware, if the memory is broken, you only need to change the memory, instead of changing the motherboard. Here the memory is an interface class, you only need to comply with the specifications, either.

One-sentence comment: to be a designer rather than a bricklayer during construction, the abstract blueprint depends on a little bit of specific materials.

4. liskov substitution principle (LSP)
The Rys replacement principle, child types must be able to replace their parent type. In the software, replace the parent class with its subclass,ProgramWill not change. It is precisely because the child type can be replaced that the module with the parent type can be expanded without modification.

In a word, when elders give you the right to inherit, you must fulfill your obligation to support your elders.

5. The dimit law (Law of Demeter)
Demeter's law,If the two classes do not need to communicate with each other directly, the two classes should not interact directly. If one class needs to call a method of another class, it can be forwarded by a third party. The weaker the coupling between classes, the more conducive it is to reuse. A class with weak coupling is modified and will not affect related classes. It mainly emphasizes the loose coupling between classes.

One comment: Do not talk to strangers. If the two countries fight, try to avoid positive conflicts and send multiple messengers for negotiation and scheduling.

6. Composition/aggregation principle (CARP)
The principle of merging and aggregation reuse should be used as much as possible, and class inheritance should not be used as much as possible. Merging and aggregation is the relationship of "has a", while inheritance is the relationship of "is. Because inheritance is a strongly coupled structure, the Child class will change as the parent class changes. Therefore, it is not an "is a" relationship. We generally do not use inheritance. The principle of merging aggregation reuse is preferred, which helps maintain the encapsulation of each class and reduce the hierarchy of inheritance.
One comment: Do not blindly multiply.