Dependency inversion principle of design pattern Principle and Design Pattern principle Inversion

Dependency inversion principle of design pattern Principle and Design Pattern principle Inversion

The Dependence Inversion Principle is dependent on abstraction, not specific. Simply put, it is to program the abstraction and do not program the implementation. This reduces the coupling between the customer and the implementation module.

For process-oriented development, the upper layer calls the lower layer, and the upper layer depends on the lower layer. When the lower layer changes dramatically, the upper layer also changes, this will reduce the reusability of modules and greatly increase the development cost. Object-Oriented development solves this problem very well. In general, the probability of abstract changes is very small, so that user programs depend on abstraction, and the Implementation Details depend on abstraction. Even if the implementation details are constantly changing, the customer program will not need to change as long as the abstraction remains unchanged. This greatly reduces the coupling between the implementation details of the customer's program domain.

Abstraction should not depend on details. Details should depend on abstraction. To put it bluntly, it is for interface programming, not for implementation programming.

The dependency inversion principle has three meanings:

1) high-level modules should not depend on low-level modules, both of which should depend on their abstraction;

2) Abstraction should not depend on details;

3) details should depend on abstraction.

Dependency inversion can be implemented in three ways.

1. Passing dependent objects through constructors. For example, the parameters to be passed in constructors are implemented through abstract classes or interfaces.

2. Pass the dependency object through the setter method. That is, the parameter in the setXXX method we set is an abstract class or interface to implement the transfer of the dependency object.

3. The interface declaration implements the dependent object, also called interface injection;

That is, when the parameter in the function declaration is an abstract class or interface, it is used to transmit the dependent object, so as to directly use the dependent object.

For ease of understanding, here are some examples of life:

1. The AGP slot. The abstraction of the relationship between the motherboard and the video card. The main board and the video card are usually connected using the AGP slot, so that as long as the interface is adapted, no matter whether the motherboard or the video card is changed, it is not a problem.

2. Driver's license. Abstract The relationship between drivers and cars. Drivers with driver licenses can drive all kinds of cars.

3. power outlet. The abstract factory model best embodies the DIP principle. In the abstract factory model, both the factory and product can be abstract. To use the factory and product interfaces, you only need to focus on them, you do not need to pay attention to the specific implementation of factories and products.

The impact of DIP on parallel development: There is a dependency between two classes. As long as the interfaces between them are developed, they can be developed in parallel.

Note: 1. What is a high-level module dependent on the underlying module?

For process-oriented development, to reuse some common code, the code is usually written as a function library. In this way, you can call these underlying functions when creating a new project. This is called a high-level module dependent on the underlying module. The high-level module is generally related to the business logic, and the underlying module is generally related to the specific implementation.

2. What is "inverted "?

This is because traditional software development methods, such as structured analysis and design, tend to create high-level modules dependent on low-level modules, abstraction dependent on specific software structures. In fact, one of the goals of these methods is to define how the upper-level module calls the lower-level module hierarchy. Therefore, the dependency structure in a well-designed object-oriented program is "put upside down" compared to the dependency structure that is usually produced by traditional procedural methods. Let's take a look at the meanings of the high-level modules that depend on the lower-layer modules. Important policy decisions and business models in an application are in these high-level modules. These models also contain the characteristics of applications. However, when these modules depend on the lower-layer modules, modifications to the lower-layer modules will directly affect them and force them to change as well. This situation is ridiculous. It should be a high-level module that forces those lower-level modules to change. A module at the upper level takes precedence over a module at the lower level. A higher-level module should not depend on a lower-level module. What we want to reuse is a high-level module. Through the sub-library form, we can reuse the lower-layer modules very well.

When a high-level module depends on a low-level module, it is difficult for these high-level modules to be reused in different environments. However, when higher-level modules are independent of lower-level modules, they can be easily reused. This is the principle at the core of the Framework Design.