Five object-oriented design principles

Single Responsibility Principle: one class, it is best to do only one thing, only one that causes its changes. The single responsibility principle can be seen as the extension of low coupling and high cohesion in the object-oriented principle. The responsibility is defined as the cause of change to improve cohesion to reduce the cause of change. There are too many responsibilities, and there may be more reasons for its change. This will lead to the dependency between duties and affect each other, which will greatly damage the cohesion and coupling. in the general sense, the single responsibility, it means that there is only one single function. Do not implement too many function points for the class to ensure that the entity has only one reason for its change.

The principle of open and closed: it is the core of all object-oriented principles. The ultimate goal of software design is to encapsulate changes and reduce coupling. The principle of open and closed is the most direct embodiment of this goal. Its core idea: software entities should be extensible and unchangeable, that is, they should be open to expansion and closed to modification.

Dependency inversion principle: dependent on abstraction. In particular, the high-level module does not depend on the underlying module, and both depend on abstraction. abstraction does not depend on specifics, but on abstraction. Dependencies must exist between classes and classes, modules and modules. When there is a close coupling between two modules, the best way is to separate interfaces and implementations: define an abstract interface between dependencies so that high-level modules can call interfaces, while underlying modules can define interfaces to effectively control the coupling of U-related relationships and achieve abstract design goals.

Interface isolation principle: use multiple small special interfaces instead of a large total interface. It is embodied in: interfaces should be cohesive, and "fat" interfaces should be avoided. The dependency of a class on another class should be built on the smallest interface. Do not force the dependency on unused methods. This is an interface pollution. The interface effectively isolates details from abstraction, reflecting all the benefits of abstract programming. Interface isolation emphasizes the singularity of interfaces. There are two main means of separation: 1. Delegate separation. By adding a new type to delegate the customer's request, the direct dependency between the customer and the interface is isolated, but it will increase the system overhead. 2. Multi-inheritance separation: it is better to implement Customer requirements through multi-inheritance through interfaces.

Liskov replacement principle: the subclass must be able to replace its base class. This idea is embodied in the constraints on the Inheritance Mechanism. Only when the subclass can replace the base class can the system identify the subclass during runtime.