[0718] operation to collect and collate the six design principles of object-oriented

Six object-oriented design principles

(1) single responsibility principle --SRP

(2) opening and closing principle --OCP

(3) the replacement in principle --LSP

(4) Dependency Inversion Principle --DIP

(5) the interface isolation principle --ISP

(6) Dmitry principle --LOD

——————————————————————————————

Single Responsibility Principle

A class, only a change in the cause of it, there is only one duty.

If a class too many responsibilities to bear, it means these functions coupled together. A change in responsibilities may weaken or inhibit the ability of this class perform other duties. This coupling will lead to fragile designs, when a change occurs, the design will suffer unexpected damage. If you want to avoid this phenomenon, we must abide by the principle of single responsibility as possible. This is the core principle of decoupling and enhance cohesion .

 

(1) can reduce the complexity of class (2) to improve the readability of maintenance class, and systems (3) When the changes, the impact of change can be minimized, because only do in this class the modification.

 

Open Closed Principle

Opening and closing the principles laid down "software objects (classes, modules, functions, etc.) should be for the extension is open , but for the modification is closed , which means that an entity is allowed to change without changing the source code of its premise its behavior . the product characteristics of the environment is particularly valuable in this environment, change the source code needs to code review, unit testing, and process to ensure product quality like. follow this principle code is not changed in the expansion, there is no need of the above-described process.

When requirements change, we need to modify the code, this time we should try to extend the original code, rather than modifying the original code, abstract framework to build, with the details to achieve expansion. When such changes occur, we will derive a direct use of the abstract class to implement concrete changes.

 

Richter substitution principle

In object-oriented programming, particularly Richter substitution principle defined sub types. "Derived class (subclass) objects in the program can replace the base class (superclass) object." Subclasses despreading functions of the parent class, but can not change the original function of the parent class. [ Richter substitution principle and the principle of opening and closing are often interdependent. ]

 

1) Subclasses may implement the abstract parent class method, but non-abstract parent class can not be covered.

2) subclass can add their own unique way.

3) When overloaded methods subclass parent class, method parameter input parameters than the parent class method looser.

4) When the implementation of the abstract subclass of the parent class, method return value more stringent than the parent class.

 

Dependency Inversion Principle

It refers to a specific decoupling (traditional dependency relationship created at a high level, and specific policy settings are applied to the low-level modules) form, so that the high-level modules do not depend on low-level implementation details module , dependencies are reversed (inverted), so that low-level module depends on a high-level abstraction module needs. High-level modules should not depend on low-level modules, both of which should rely on its abstract; abstract should not rely on details; details should depend on the abstract. Depends on the abstract, do not rely on specific.

 

 Interface Segregation Principle

The client should not rely on methods that do not use. A plurality of interface isolation, is better than using a single interface. The purpose is to unlock the coupling system, which is easy to reconstruct, alter and re-deployment. In object-oriented design, an interface (interface) provides an abstraction layer to facilitate the explanation on the concept of the code, and creates a barrier to avoid dependency.

The establishment of a single interface, do not create bloated interface, try to refine the interfaces, interface methods as little as possible .

 △ Interface segregation principle using Note:

1) interfaces as small as possible, but there's a limit. The interfaces can be refined to improve the flexibility of the fact that programming is not earned, but if it is too small, it will cause excessive number of interfaces, complicating the design. So be sure to moderate.
2) is dependent on the interface class customized services, only expose the class to call the method it needs, it does not require the method is hidden. Only focus on providing customized services for a module in order to establish the minimum dependencies.
3) improve cohesion and reduce the external interaction. The interfaces with the least method to accomplish most things.

 

Dmitry principle

An object should be kept to a minimum understanding of other objects . Because the more general principle of the close relationship between class and class, the greater the degree of coupling, when a class is changed, the impact on the greater of another class, so this is our advocate of software programming: the low coupling and high cohesion. A class of their dependent classes know better. That is, for the dependent classes, no matter how complex logic, as much as possible to the internal logic is encapsulated in the class, the external addition method provided by the public, without leaking any information outside.

 

Guess you like

Origin www.cnblogs.com/yanglanlan/p/11222995.html