table of Contents
Six principles of object
- Single Responsibility Principle (Single Responsibility Principle SRP)
- Open Closed Principle (Open Close Principle OCP)
- Richter substitution principle (Liskov Substitution Principle LSP)
- Dependency Inversion principle (Dependence Inversion Principle DIP)
- Interface Segregation Principle (Interface Segregation Principle ISP)
- Dimitris principle (Least Knowledge Principle LKP)
Single Responsibility Principle
A class, it is best to do only one thing, only one of the causes of its changes .
Single responsibility principle can be seen as a low coupling, the high polymer in the object-oriented principle of extension, defined responsibilities cause changes to improve cohesion to reduce the causes of variation. The more reason for excessive duties, it may cause a change, which will result in dependent functions, to influence each other, thus greatly damage the inner cohesion and coupling. Single Responsibility in common sense, refers to only one single function, not to implement too many function points as a class, to ensure that the entity is only one reason for changes caused by it.
Open Closed Principle
Software entities should be scalable, and can not be modified. That is, open for extension, closed for modification .
Open Closed Principle is mainly reflected in two aspects
1, open for extension means that there are new requirements or changes in existing code can be extended to adapt to new circumstances.
2, closed for modification means that the class once the design is complete, you can complete its work independently, but do not make any changes or attempts.
The core idea is to abstract programming, because the abstract is relatively stable. Let class relies on a fixed abstraction, so the modification is closed; and object-oriented mechanisms of inheritance and polymorphism, and inheritance to be an abstract class, to change the natural behavior by overriding its methods, new development methods to achieve, so it is open. "The demand is always changing," not the same software, so you need to use the principles of open closed closed changes to meet demand, while maintaining the internal stability of the system software package, not affected by changes in demand.
Richter substitution principle
Subclasses must be able to replace its base class .
This thinking is reflected as a constraint specification of the inheritance mechanism, only subclasses can replace the base class, in order to ensure that the system identifies the subclass operation period, which is to ensure succession on the basis reuse. In the specific behavior of the parent class and subclass must be strictly grasp the relationships and characteristics of inheritance hierarchy, will replace the base class is a subclass, the behavior of any changes will not occur. Meanwhile, in turn, this constraint is not established, the subclass can replace the base class, the base class but not be able to replace the subclass.
Liskov substitution principle, the main focus on abstract and polymorphic built on the basis of inheritance, only to follow the Liskov substitution principle, in order to ensure succession reuse is reliable. This is accomplished by programming to an interface: public abstract base class interface portion or abstract class, by Extract Abstract Class, support the same functions in subclasses to achieve a new way by the process of overwriting the parent class.
Liskov Substitution Principle is designed on the principle of inheritance, in violation of the substitution principle Liskov will inevitably lead to violations of the open closed principle.
Alternatively Liskov principle to ensure the system has good scalability, while achieving polymorphism based abstraction, it is possible to reduce code redundancy, to avoid type discrimination operation period.
Dependency Inversion Principle
Depend on abstractions .
Specifically layer module is not dependent on the underlying module, both depend on the same abstract; abstract does not depend on specific, dependent on the particular abstraction.
We know that dependence will exist in between classes, modules and module. When there is a close coupling between two modules, the best way is to separate interface from implementation: define an abstract interface layer module so that the dependence between the call interface module implements the underlying interface definition, in order to efficiently control the coupling relationship, and thus depends on the abstract design goals.
Abstract stability determines the stability of the system, because the abstract is constant, depends on the abstraction is the essence of object-oriented design, but also the Dependency Inversion Principle core. Depends on the abstract, that is, programming interfaces, not to implement programming.
Interface Segregation Principle
Use multiple small dedicated interface instead of a large total interfaces .
Specifically, the interface segregation principle is reflected in: the interface should be cohesive, should avoid "fat" interface. A class dependent on another class should be built on a minimum of interfaces, do not force do not depend on the method, which is an interface contamination. Interface effectively isolate details and abstract, reflecting the benefit of all abstract programming interface isolation emphasize unity interface. The fat Interface obvious drawbacks, will lead to the type of implementation must fully implement all the methods, properties, and other interfaces; and sometimes, need not achieve all type of interface definition, which is in the design of "waste", and in the implementation of this poses a potential problem, modify the interface of fat will lead to a series of client programs need to be modified, sometimes it is a disaster. In this case, the interface fat decomposition method of a plurality of customization features, so that the client depends only on practical methods for their calls to release the client does not depend on the method thereof.
Means isolated mainly in the following two ways:
1, commissioned by separation, by adding a new type of customer request to delegate, isolation and depend directly on the customer interface, but will increase the cost of the system.
2, multiple inheritance separation, to achieve customer needs through the interface of multiple inheritance, this is a better way.
Dimitris principle (the principle of the least known)
Object should have a minimum of understanding and other objects .
Popular speaking, a class of their own needs should be coupled or at least call the class know how to achieve inner class has nothing to do with the call-dependent, or dependent on the caller only needs to know the way he needs to, others may not care. Between classes closer the relationship, the larger the coupling, when a class is changed, the greater the effect on another class if the two classes do not have to communicate directly, then it should not be two classes of direct interaction. If a class needs to call methods of another class, this can be forwarded by a third-party call an object to other objects should be kept minimal understanding of
the Law of Demeter mind is the coupling between the lower class, but everything has a degree, Although communication between the indirect type can be avoided, but it must be communicated to a relationship through an intermediary; the use of excessively Demeter, will generate a lot of such transfer and intermediary classes, resulting in increased complexity of the system . Therefore, the use of Demeter, to weigh, is necessary to achieve a clear structure but also the high cohesion and low coupling.