1. Single Responsibility Principle: (Single Responsibility Pinciple)
A class is responsible for only one responsibility, one thing. When more than one responsibility needs to be responsible, a new class needs to be added to be responsible for the new responsibility, rather than adding new code to the class.
If a class has too many responsibilities, it is highly coupled with responsibilities, which is very unfavorable for extending functions. This is a very fragile design. It is easy to modify one place and affect other places.
Advantages of following the Single Responsibility Principle:- Reduce class complexity
- Improve the readability of classes and improve the maintainability of the system
- Risk reduction due to change
2. Liskov Substitution Principle: A subclass can extend the functions of the parent class, but cannot change the original function of the parent class.
Contains 4 layers of meaning:
- Subclasses can implement abstract methods of superclass, but cannot override non-abstract methods of superclass.
- Subclasses can add their own unique methods.
- When the method of the subclass overrides the method of the superclass, the preconditions of the method (that is, the formal parameters of the method) are more relaxed than the input parameters of the superclass method.
- When the method of the subclass implements the abstract method of the superclass, the postconditions of the method (that is, the return value of the method) are stricter than those of the superclass.
The consequence of not following the Liskov substitution principle is that the chances of writing code errors are greatly increased.
3. Dependence Inversion Principle: (Dependence Inversion) High-level modules should not depend on low-level modules, both should depend on abstraction.
The abstract should not depend on the concrete, the concrete should depend on the abstract.
The Dependency Inversion Principle is based on the fact that abstract things are much more stable than details are variable. Architectures built on abstraction are much more stable than architectures built on details. In java, abstract refers to an interface or abstract class, and details are specific implementation classes. The purpose of using interfaces or abstract classes is to formulate specifications and contracts, without involving any specific operations, and leave the task of showing details to their implementation class to complete.
The core idea of the Dependency Inversion Principle is interface-oriented programming, not implementation-oriented programming.
In the traditional development architecture, controller-->service-->dao follows the dependency inversion principle. The controller calls the service is the API, and the service calls the dao also calls the API. In this way, changes in implementation details in the API will not affect the caller of the API.
4. Demeter's Principle: An object should have the least knowledge of other objects.
Also known as the least known principle.
In layman's terms, the less a class knows about the classes it depends on, the better.
That is to say, for the dependent class, no matter how complicated the logic is, try to encapsulate the logic inside the class as much as possible, and do not leak any information to the outside except for the public methods provided.
The Law of Demeter has an even simpler definition: Only communicate with immediate friends.
General principles of software programming: low coupling, high cohesion.
Whether it is procedural programming or object-oriented programming, the code reuse rate can be improved only if the coupling between each module is as low as possible.
The principle of Demeter is to reduce the coupling between classes.
5. Open-closed principle: open for extension, closed for modification.
A software entity, such as classes, modules, and functions, is open for extension and closed for modification.
Origin of the problem: During the life cycle of the software, when the original code of the software needs to be modified due to changes, upgrades and maintenance, etc., errors may be introduced into the old code, or we may have to refactor the entire function. And the original code needs to be retested.
Solution: When the software needs to change, try to achieve the change by extending the behavior of the software entity, rather than modifying the existing code to achieve the change.
The open-closed principle is nothing more than trying to express such a meaning: build a framework with abstraction and extend details with implementation. Because the abstraction is flexible and adaptable, as long as the abstraction is reasonable, the stability of the software architecture can be basically maintained. For the volatile details in the software, we use the implementation class derived from the abstraction to extend. When the software needs to change, we only need to re-derived an implementation class to extend according to the requirements. Of course, the premise is that our abstraction must be reasonable, and we must be forward-looking and predictable for changes in demand.
前面说的5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。