5 basic design principles of object-oriented

3 basic elements of object-oriented: encapsulation, inheritance, polymorphism

Object-oriented 5 basic design principles:

single Duty principle (Single-resposibility Principle)

Its core idea is: A class, it is best to do only one thing, only a change that caused it. The principle of single responsibility can be regarded as the extension of low coupling, cohesion in object-oriented principle, defining responsibility as the cause of change, in order to improve cohesion to reduce the cause of 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. A single function in the general sense is that there is only one single feature, and do not implement too many functional points for the class to ensure that the entity has only one cause for it to change.
Focus, is a person's excellent quality; the same, single is also a good design of a class. Mixed's unclear responsibilities will make the code look particularly awkward reaching, have a loss of beauty and inevitably lead to an ugly system error risk.

Open Closure principle (open-closed principle)

The core idea is that software entities should be extensible and non-modifiable. That is, open to the extension, to modify the closed. The principle of open closure is mainly 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 implementing open and closed closure principle is to abstract programming, but 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.
"Demand always changes" there is no immutable software, so it is necessary to use closed open principle to close the change to meet demand, but also to maintain the internal software packaging system stability, not affected by the change in demand.

Liskov Substitution principle (liskov-substituion Principle)

The core idea is that subclasses must be able to replace their base classes. This idea is embodied in the constraints of inheritance mechanism, only the subclass can replace the base class, it can ensure that the system in the runtime to identify the subclass, which is the basis of ensuring inheritance reuse. In the specific behavior of the parent class and subclass, you must strictly grasp the relationship and characteristics in the inheritance hierarchy, replace the base class with the subclass, and the behavior of the program will not change. At the same time, this constraint, in turn, is not true, and the subclass can replace the base class, but the base class does not necessarily replace the subclass.
The Liskov substitution principle mainly focuses on the establishment of abstraction and polymorphism on the basis of inheritance, so only by following the principle of Liskov substitution can we ensure that inheritance reuse is reliable. The way to do this is to interface-oriented programming: to abstract the public part into a base class interface or abstract class, and to support the same responsibilities in a subclass by extract the method of the parent class through the abstraction class.
The Liskov substitution principle is about the design principle of the inheritance mechanism, violating the principle of Liskov substitution inevitably leads to violating the principle of open closure.
The Liskov substitution principle can ensure that the system has good extensibility and realizes the abstraction mechanism based on polymorphism, which can reduce the code redundancy and avoid the type discriminant of the running period.

dependency Inversion principle (dependecy-inversion Principle)

The core idea is that it relies on abstraction. In particular, high-level modules do not rely on the underlying modules, both of which are dependent on abstraction;
We know that dependencies must 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.
Dependence on abstraction is a common principle, and sometimes it is unavoidable to rely on details, and it is necessary to weigh the trade-offs between abstraction and specificity, not the same way. Depending on the abstraction, it is programming the interface, not programming the implementation.

Interface Isolation principle (interface-segregation Principle)

The core idea is to use multiple small, dedicated interfaces instead of a large total interface.
Specifically, the principle of interface isolation is that the interface should be cohesive, and the "fat" interface should be avoided. The dependency of a class on another class should be based on the smallest interface, and do not force reliance on the unused method, which is an interface pollution.
Interfaces effectively isolate detail and abstraction, embodying all the benefits of abstract programming, and interface isolation emphasizes the uniqueness of interfaces. But the fat interface has the obvious disadvantage, causes the realization the type must completely implement the interface all methods, the property and so on, but some time, the implementation type does not need all the interface definition, in the design this is "The waste", and in the implementation this will have the latent problem, the modification of the Fat interface will cause a series of client program to modify , sometimes it's a disaster. In this case, the decomposition of the Fat interface into a number of characteristics of the customization method, so that the client only relies on their actual invocation of the method, thereby relieving the client does not rely on the methods they do not use.
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.

These are the 5 basic object-oriented design principles, which are like the golden rule in object-oriented programming, which can make our code more vivid, easy to reuse, easy to expand, and flexible and elegant. Different design patterns correspond to different requirements, while design principles represent the eternal soul, which needs to be adhered to in practice. As Arthur J.riel in the revelation of Ood there: "You do not strictly abide by these principles, and you will not be punished by the punishment of religion against them." But you should think of these principles as alarms, and if you violate one of them, the alarm will ring. ”

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