Object oriented thought--object oriented design principle

Short for solid

1. Single Responsibility Principle

Responsibility is defined as the cause of the change. A class, it is best to do only one thing, only a change that causes it. Do not implement too many functional points for the class to ensure that the entity has only one cause for it to change. The more responsibilities that may cause it to change, the more it will lead to a dependency on responsibility, which has an impact on each other, thus greatly damaging the cohesion and coupling degree.

2. Open Closure principle

　　Open for expansion, closed for modification. Embodied in two aspects 1, open to expansion, means that there are new requirements or changes, you can extend the existing code to adapt to the new situation. 2, to modify the closure, means that once the design of the class, you can complete its work independently, and do not make any attempt to modify it.
The core idea of implementation is to abstract programming, not specific programming, because the abstraction is relatively stable. So that the class depends on the fixed abstraction, so the modification is closed , and through the object-oriented inheritance and polymorphism mechanism, it can realize the inheritance of the abstract class, by covering its methods to change the inherent behavior , to realize the new expansion method, so it is open .
3. Replacement principle

Subclasses must be able to replace their base classes. Inheritance must ensure that the properties owned by the superclass remain in the subclass. "That is, when an instance of a subclass should be able to replace any instance of its superclass, there is a is-a relationship between them. Replacing a base class with a subclass does not change the behavior of the program. This constraint, in turn, is not tenable. When inheriting and overriding a superclass method, the visibility of a method in a subclass must be equal to or greater than the visibility of a method in a superclass, and a method in a subclass throws an exception that is only a subclass of the exception that is thrown by the corresponding method in the superclass.

4. Dependency Inversion principle

relies on abstraction. In particular, high-level modules do not rely on the underlying modules, both of which are dependent on abstraction. Depending on the abstraction, it is programming the interface, not programming the implementation.
Dependencies are bound to exist between classes and classes, modules, and modules. When there is a tight coupling between the two modules, the best way is to separate the interface and implementation: To define an abstract interface between dependencies so that the high-level module calls the interface, and the underlying module to implement the definition of the interface, so as to effectively control the coupling relationship, to rely on the abstract design goals.
Abstract stability determines the stability of the system, because the abstraction is constant, the dependence on abstraction is the essence of object-oriented design, but also the core of the dependency inversion principle.

5. Interface Isolation principle　　

The dependency of a class on another class should be based on the smallest interface, not forced to rely on unused methods. An interface represents a role, and different roles should not be handed over to an interface.

The main methods of separation are the following two kinds: 1, the separation of delegates, by adding a new type to entrust the customer's request, isolate the client and interface direct dependence, but will increase the system overhead. 2, multiple inheritance separation, through the interface multiple inheritance to achieve customer demand, this way is better.

Reference: http://blog.csdn.net/luxiaoxun/article/details/8041885

Object oriented thought--object oriented design principle