Agile Software development – dip dependency inversion principle

DIP Dependency Inversion principle

1. High-level modules should not be dependent on low-layer modules. Both should be dependent on abstraction.
2. Abstraction should not depend on detail. The details should depend on abstraction.

What does it mean to rely on the high-level modules of the lower modules? It is the high-level module that contains important policy choices and business models in the application. These high-level modules make their application different from the others. However, if these high-level modules are dependent on lower-layer modules, changes to the lower-level modules will directly affect the upper-layer modules, forcing them to make changes in turn. High-level modules can be reused very easily if they are independent of the lower-level modules. This principle is the core principle of frame design.

Hierarchy of

Bad hierarchical relationship.

A more suitable model. Each higher layer declares an abstract interface for the service it needs. These abstract interfaces are implemented at a lower level. Each high-level class uses the next layer through the abstract interface. Such a high level is not dependent on the lower levels. The lower layer relies instead on the abstract service interface declared in the upper layer. This not only relieves the policylayer of the Utilitylayer, but also relieves the policylayer of the dependency on Mechanismlayer.

Upside-down interface ownership

Inversion is not just an inversion of dependency, it is also an inversion of the ownership of the interface. We generally assume that the ToolPak should have its own interface. But 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." (Do not invoke us, we will invoke you.) The low-level module implements an interface declared in a high-rise module and called by a high-level module.

With this inverted interface ownership, any changes to Mechanismlayer and Utilitylayer will no longer affect Poliylayer. Furthermore, Policylayer can be reused in any context that defines a conforming policyserviceinterface. Thus, by inverting these dependencies, we create a more flexible, durable, and easily changing structure.

Ownership in this case simply means that the interface is distributed with the client program that owns them, not the server program that implements them. The interface and the client are in the same package or library. This forces the server library or package to depend on the client library or package.

Of course, sometimes we don't want to let the server program rely on the client program, especially when there are multiple client programs but only one copy of the server. In this case, the client program must follow the service interface and publish it to a separate package.

Dependent on abstraction

All dependencies in a program should be terminated in an abstract class or interface.

• Any variable should not hold a reference to a specific class.
• No class should derive from a specific class.
• No method should override a method that has already been implemented in any of its base classes.

Of course, every program will have a violation of this heuristic rule. Sometimes you must create instances of specific classes, and the modules that create them will depend on them. Moreover, the heuristic rules seem unreasonable to those who are specific but stable. If a specific class is less likely to change and does not create other similar derived classes, then relying on it does not cause damage.

For example, in most systems, the classes that describe strings are specific. For example, a string in C #. The class is stable. In other words, it's not going to change much. Therefore, direct reliance on it does not cause harm.

If the interface of an unstable class must change, this change must affect the abstract interface that represents the class. This change destroys the isolation that is maintained by the abstract interface.

As a rule, the heuristic rules are a little easier to think about. On the other hand, if you look farther and think that the client module or layer declares the service interface they need, the interface is changed only when the customer needs it. Thus, changing the class that implements the abstract interface does not affect the customer.

Find out the potential abstraction

Interfaces can be used by many different customers and implemented by many different service providers. In this way, the interface needs to exist independently and not belong to either party. In C #, you can put it in a separate named control and library.

Conclusion

The dependency structures and policies that are created using traditional procedural programming are dependent on the details. This is bad because it makes the strategy subject to changes in detail. Object-oriented programming inverts the dependency structure, making the details and strategy dependent on abstraction, and often the client program has a service interface.

In fact, this dependency inversion is the hallmark of good object-oriented design. It doesn't matter what language you are programming with. If the dependency of a program is inverted, it is an object-oriented design. If the dependencies of the program are not inverted, it is a process-based design.

The dependency inversion principle is a basic low-level mechanism for realizing the benefits claimed by many object-oriented technologies. Its correct application is necessary to create a reusable framework. It is also important for building code that is resilient in the face of change. Because abstractions and details are isolated from each other, the code is also very easy to maintain.

Excerpt from: [Mei]robertc.martin, Micahmartin, Aaron, Sun Yu translation Agile Software Development principles, patterns and practices (C # revision) [M], People's post and Telecommunications publishing house, 2013, 115-121,

Agile Software development – dip dependency inversion principle