- Six design principles
Let's look at a picture first:
This picture clearly expresses the six design principles, but only what are they called, what do they mean? In the following, I will elaborate on the four aspects of the original text, translation, understanding and application.
1. Single Responsibility Principle (Single Responsibility Principle - SRP)
原文：There should never be more than one reason for a class to change.
Translation: There should never be more than one reason to change a class.
Understanding: For a class, there should be only one reason for it to change. To put it bluntly, different classes have different responsibilities and perform their own responsibilities. This is like a team, where everyone divides their work and cooperates without affecting each other, each doing its own thing.
Application: When we do system design, if we find that a class has two kinds of responsibilities, then ask yourself a question: Can this class be divided into two classes? If it's really necessary, divide it. Never let a class do too much!
2. Open Closed Principle (OCP)
原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.
Translation: Software entities, such as classes, modules, and functions, should be open for extension, but closed for modification.
Understanding: In short, open for extension, closed for modification. In other words, you can extend the class, but don't modify the class.
Application: When the requirements are changed and the code needs to be modified, what you need to do at this time is to extend the functions of the class by inheritance or combination as much as possible, instead of directly modifying the code of the class. Of course, if you can ensure that it will not have any impact on the overall architecture, then there is no need to make it so complicated, just change this class directly.
3. Liskov Substitution Principle (LSP)
原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
Translation: A function that uses a pointer or reference to a base class must be able to use an object of the derived class without knowing it.
Understanding: The parent class can replace the child class, but the child class cannot necessarily replace the parent class. That is to say, all parent classes can be replaced with subclasses in the code, and the program will not report an error, nor will any exception occur at runtime, but the reverse is not necessarily true.
Application: When inheriting a class, be sure to override all the methods in the parent class, especially pay attention to the protected methods of the parent class (they are often for you to override), and try not to expose your own public methods to the outside world. transfer.
The principle was proposed by Ms. Barbara Liskov of the Massachusetts Institute of Technology, who was the first woman in the United States to receive a doctorate in computer science and has also won the Turing Award for Computers.
4. Least Knowledge Principle (LKP)
原文：Only talk to you immediate friends.
Translation: Only communicate with your closest friends.
Understanding: Minimize interaction between objects, thereby reducing coupling between classes. In short, it must be done: low coupling, high cohesion.
Application: When doing system design, don't let a class depend on too many other classes, and try to reduce the dependencies as much as possible, otherwise, you will die without knowing how you died.
This principle is also known as the "Law of Demeter" and was developed by Ian Holland. The man was reluctant to talk to strangers and only communicated with his closest friends.
5. Interface Segregation Principle (ISP)
原文：The dependency of one class to another one should depend on the smallest possible interface.
Translation: Dependencies between one class and another should depend on the smallest possible interface.
Understanding: Do not expose interfaces that have no practical significance. In other words, the interface is called for others, so don't make it difficult for others, and try to ensure the practicability of the interface as much as possible. She is fine, so am I.
Application: When you need to expose the interface to the outside world, you need to consider it again and again. If it is really unnecessary to provide it externally, delete it. Once you provide it, it means that you have one more thing to do in the future, why bother to find something for yourself.
6. Dependence Inversion Principle (DIP)
原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
Translation: High-level modules should not depend on low-level modules, they should depend on abstractions. Abstractions should not depend on details, and details should depend on abstractions.
Understanding: programming should be oriented towards the interface, not towards the implementation class. Implementation-oriented programming is equivalent to discussing things, which is positive dependence (normal people's thinking); interface-oriented programming is equivalent to looking at the essence through the appearance of things, which is reverse dependence, that is, dependency inversion (programmer thinking).
Application: It does not mean that all classes must have a corresponding interface, but that if there is an interface, try to use the interface to program.
Putting together the English initials of the above six principles is SOLID (stable), so it is also called the SOLID principle.
Only when these six principles are met, can a stable software architecture be designed! But they are only principles after all, they are just suggestions given to us by the gang of four. Sometimes we still need to learn to be flexible and adapt to changes. Don't be rigid, otherwise it will only complicate simple problems, remember!
- Supplemental Design Principles
1. Composition/Aggregation Reuse Principle - CARP
When extending the functionality of a class, use composition in preference to inheritance. This principle is frequently used in 23 classic design patterns, such as: proxy pattern, decorator pattern, adapter pattern, etc. It can be seen that the status of rivers and lakes is very high!
2. Acyclic Dependencies Principle (ADP)
A circular dependency occurs when module A depends on module B, module B depends on module C, and module C depends on module A. This problem should be avoided in the design and can be solved by introducing the "mediator pattern".
3. Common Closure Principle (CCP)
Mutable classes should be placed in the same package to isolate changes. This principle is an extension of the "open-closed principle".
4. Common Reuse Principle (CRP)
If you reuse a class in the package, it is equivalent to reusing all the classes in the package, and we want to reduce the size of the package as much as possible.
5. Hollywood Principle (Hollywood Principle - HP)
Agents of Hollywood stars are generally very busy, they don't want to be disturbed, they often say: Don't call me, I'll call you. Translated as: Don't call me, I'll call you. Corresponding to software design, the most famous is "inversion of control" (or "dependency injection"), we do not need to actively create objects in the code, but let the container help us create and manage these objects.
- Other Design Principles
1. Don't repeat yourself - DRY
Don't have duplicate code everywhere, make them reusable enough, so encapsulate as much as possible.
2. Keep it simple and stupid (Keep it simple and stupid - KISS)
Don't make the system complicated, the interface is simple, the functions are practical, and the operation is convenient, and it should be simple enough and fool enough.
3. High Cohesion and Low Coupling (HCLC)
Modules need to have a high degree of cohesion, and modules need to have a low degree of coupling.
4. Convention over Configuration (COC)
Try to use conventions to reduce configuration, so as to improve development efficiency and try to achieve "zero configuration". Many development frameworks do this.
5. Command Query Separation (CQS)
When defining an interface, do what is a command and what is a query, and separate them, not clump them together.
6. Separation of Concerns (SOC)
Divide a complex problem into multiple simple problems, and then solve these simple problems one by one, then the complex problem is solved. The difficulty is how to separate.
7. Design by Contract (DBC)
Interactions between modules or systems are based on contracts (interfaces or abstractions), not on specific implementations. This principle suggests that we should program for contracts.
8. You aren't gonna need it - YAGNI
Don't design the system to be very complex in the first place, and don't fall into the abyss of "over-engineering". The system should be simple enough without losing scalability, which is the difficulty.