Five basic object-oriented design principles

Three basic elements of object-oriented architecture: encapsulation, inheritance, and Polymorphism

Five basic object-oriented design principles:

Single-Resposibility Principle)

Its core idea is: A class. It is best to do only one thing and only one change that causes it. 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. Too many responsibilities may lead to more reasons for its changes. This will lead to dependency between duties and affect each other, greatly damaging their cohesion and coupling. In general, a single responsibility refers to a single function. Do not implement too many function points for the class to ensure that the entity has only one reason for its change.
Focus is a person's excellent quality. The same, single is also a class of excellent design. The ambiguous responsibilities will make the Code look awkward, without aesthetic feeling and the risk of ugly system errors.

Open-closed Principle)

The core idea is: software entities should be scalable and unchangeable. That is, it is open to expansion and closed to changes. The open and closed principle is mainly embodied in two aspects: 1. Opening to expansion means that existing code can be expanded to adapt to new situations when new requirements or changes exist. 2. Closed changes mean that once the class is designed, it can complete its work independently, instead of making any changes to it.
The core idea of implementing the Open, open, and closed principle is abstract programming, which is not accurate and detailed, because the abstraction is relatively stable. Classes depend on fixed abstractions, so changes are closed. Through Object-oriented Inheritance and polymorphism, classes can inherit abstract classes, by overwriting its methods to change the inherent behavior and implement new expansion methods, it is open.
There is no constant software in "demand is always changing", so we need to use the closed open principle to close the changes to meet the demand. At the same time, the internal packaging system of the software can be kept stable, it is not affected by changes in demand.

Liskov replacement principle (liskov-substituion principle)

The core idea is that child classes must be able to replace their base classes. This idea is embodied in the constraints on the Inheritance Mechanism. Only when a subclass can replace the base class can the system identify the Child class during the execution period, which is the basis for ensuring inheritance reuse. In the detailed behavior of the parent class and Child class, you must strictly grasp the relationship and features in the inheritance layer and replace the base class with the Child class. The behavior of the program will not change regardless of the behavior. At the same time, this constraint is not true in turn. Child classes can replace the base class, but the base class may not necessarily replace the child class.
The liskov replacement principle mainly focuses on the Inheritance of abstraction and polymorphism. Therefore, it only follows the liskov replacement principle to ensure that inheritance reuse is reliable. The implementation method is interface-Oriented Programming: Abstract The public part as a class interface or abstract class, through extract abstract class, in the subclass, override the parent class to implement a new method that supports the same responsibilities.
The liskov replacement principle is about the design principle of the Inheritance Mechanism. Violation of the liskov replacement principle will inevitably lead to a violation of the open and closed principle.
The liskov replacement principle ensures that the system has excellent scalability. At the same time, the implementation of the abstract Mechanism Based on Polymorphism can reduce code redundancy and avoid type discrimination during the execution period.

Dependency inversion principle (dependecy-inversion principle)

Its core idea is to rely on abstraction. In detail, the high-level module does not depend on the underlying module, both of which depend on abstraction; abstraction does not depend on detail, and details depend on abstraction.
We know that dependencies must exist between classes, classes, modules, and modules. When there is a close coupling relationship between the two modules, the best way is to separate the interface and implementation: Define an abstract interface between dependencies so that the high-level module calls the interface, the underlying module implements the interface definition to effectively control the coupling relationship and achieve the abstract design goal.
Abstract stability determines the stability of the system. Because abstraction remains unchanged, dependency on abstraction is the essence of object-oriented design and is also the core of dependency inversion principle.
Dependency on abstraction is a general principle. In some cases, dependency on details is inevitable. The trade-off between abstraction and detail must be weighed. methods are not the same layer. The dependency on abstraction means programming interfaces rather than implementing programming.

Interface-segregation principle)

The core idea is to use multiple small specialized interfaces instead of a large total interface.
In details, the interface isolation principle is embodied in the following: 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 advantages of abstract programming. Interface isolation emphasizes the singularity of interfaces. The fat interface has obvious drawbacks, which may lead to the need to fully implement all methods and attributes of the interface. In some cases, not all interface definitions are required for the Implementation type, this is a "waste" in design and may lead to potential problems in implementation. Changes to the fat interface will lead to a series of client programs to be changed. Sometimes this is a disaster. In this case, the fat interface is divided into multiple customized methods, so that the client only depends on the methods actually called, thus, removing the client will not depend on the methods they do not need.
There are two main means of separation: 1. By adding? A new type is used to trust the customer's request and isolate the direct dependency between the customer and the interface? System overhead. 2. Multi-inheritance separation: it is better to implement Customer requirements through multi-inheritance through interfaces.

The above five are the main object-oriented design principles. They are like the Golden laws in Object-Oriented Programming. Complying with them can make our code more vivid, reusable, scalable, flexible, and elegant. Different design patterns correspond to different needs, while design principles represent the eternal soul and must be observed in practice all the time. As Arthur J. riel said in the "Ood inspiration book", "you do not have to strictly abide by these principles and violate them and will not be sentenced to religious penalties. But you should regard these principles as warning bells. If you violate one of them, the warning bells will ring ."

Principle of object-oriented design http://www.cnblogs.com/feipeng/archive/2007/03/02/661840.html