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 will cause 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. 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 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.
Focus is a person's excellent quality. Similarly, a single is also a class of excellent design. The ambiguous responsibilities will make the Code look awkward, causing a risk of aesthetic and ugly system errors.

Open-closed Principle)

The core idea is that software entities should be extensible and cannot be modified. That is, it is open to extensions and closed to modifications. The open and closed principle is mainly embodied in two aspects: 1. Open to expansion means that existing code can be expanded to adapt to new situations when new requirements or changes exist. 2. Closed modification means that once the class is designed, it can complete its work independently without any attempt to modify it.
The core idea of implementing the open and closed principle is to abstract programming, rather than specific programming, because the abstraction is relatively stable. Classes depend on fixed abstractions, so modifications are closed. Through Object-oriented Inheritance and polymorphism, classes can be inherited from abstract classes, by overwriting its methods to change the inherent behavior and implement new expansion methods, it is open.
"Demand is always changing" without changing software, so we need to use the closed open principle to close the changes to meet the requirements, while maintaining the stability of the software's internal packaging system, it is not affected by changes in demand.

Liskov replacement principle (liskov-substituion principle)

Its 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 the child class can replace the base class can the system identify the Child class during the runtime, which is the basis for ensuring inheritance reuse. In the specific 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. 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, only by following the liskov replacement principle can we 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 violation of the open and closed principle.
The liskov replacement principle can ensure the system has good scalability, and at the same time implement the abstract Mechanism Based on polymorphism, which can reduce code redundancy and avoid type discrimination during runtime.

Dependency inversion principle (dependecy-inversion principle)

Its core idea is to rely on abstraction. Specifically, the high-level module does not depend on the underlying module, both of which depend on abstraction; abstraction does not depend on specifics, and abstraction depends on specifics.
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.
The stability of abstraction determines the stability of the system, because abstraction remains the same, relying on abstraction is the essence of object-oriented design, and is also the core of the dependency inversion principle.
Dependency on abstraction is a general principle. In some cases, dependency on details is inevitable. The trade-off between abstraction and details 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.
Specifically, the interface isolation principle 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. Fat interfaces have obvious drawbacks, which may lead to the full implementation of all methods and attributes of interfaces. In some cases, not all interface definitions are required for implementation types, this is a waste of design, and it may lead to potential problems in implementation. Modifying the fat interface will lead to a series of client programs to be modified. 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 from relying on the methods they do not need.
There are two main means of separation: 1. Delegate separation, by adding a new type to delegate the customer's request, isolate the direct dependency between the customer and the interface, but it will increase the system overhead. 2. Multi-inheritance separation: it is better to implement Customer requirements through multi-inheritance through interfaces.

The above five basic object-oriented design principles 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 good revelation over there: "You do not have to strictly abide by these principles, and violation of them will not be subject to religious penalties. But you should regard these principles as warning bells. If you violate one of them, the warning bells will ring ."

Object-Oriented Design Principles

Http://www.cnblogs.com/feipeng/archive/2007/03/02/661840.html