[Agile design] 5. Dip Dependency inversion principle

I. Definition

1. High-level modules should not depend on low-level modules, both of which should depend on abstraction

2. abstraction should not depend on details. Details should depend on abstraction

2. Hierarchical

1. Brief Introduction

A well-structured object-oriented architecture has a clear hierarchy definition, and each layer provides services in a group through a well-defined and controlled interface.

A simple understanding of this statement may lead the designer to design a similar structure.

　　　　

As shown in the figure, the policy layer of the higher layer uses the lower-layer mechanism layer, while the mechanism layer uses the more detailed utility layer. In this way, the policy layer is sensitive to changes to the following utility layer. This dependency is passed. This is very bad.

A more suitable model is displayed. Each high-level layer declares an abstract interface for the required service. These abstract interfaces are implemented at a lower level. Each high-level class uses the next layer through this abstract interface, so that the High-level class does not depend on the lower layer. The lower layer depends on the abstract service interface declared in the higher layer. This removes the dependency between the policy layer, the Mechanism layer, and the utility layer.

　　　　

2. Inverted interface ownership

The inversion here is not only the inversion of dependency, but also the inversion of interface ownership.

However, when dip is applied, we find that customers often have abstract interfaces, and their service providers derive from these abstract interfaces.

This is the famous Hollywood principle: "Don't call us, we'll call you. (Don't look for us, we'll find you )".

The lower-level module implements the interface declared in the higher-level module and called by the higher-level module.

Principles of Hollywood:

// Do not apply iocclass A {B = new B ();} // apply IOC Class A {B = NULL; // you do not need to find B by yourself, when you need it, B will automatically initialize it for you. Public A (B) {This. B = B ;}}

The interface ownership caused by this will not affect the policy layer any changes made to the tasks at the mechanism or utility layer. In addition, the Policy layer can define any context reuse that meets policyserviceinstance. By reversing these dependencies, we have created a more flexible, persistent, and changed structure.

3. dependent on abstraction

Dependent on abstract suggestion we should not rely on specific classes -- that is to say, all dependencies in the program should end with abstract classes or interfaces.

• No variable should hold a reference pointing to a specific class.
• No class should be derived from a specific class
• No method should overwrite any implemented methods in any of its base classes. Sometimes, you must create instances of specific classes, and the created modules will depend on them, if a specific class does not change much and other similar Derived classes are not created, dependent on it will not cause damage.

Iii. Conclusion

In fact, the result of this dependency is exactly the sign of a good object-oriented design. It is irrelevant to the language used for programming. If the program dependency is inverted, it is an object-oriented design. If the program dependency is not inverted, it is a procedural design.

[Agile design] 5. Dip Dependency inversion principle