Dependency reversal principle (Dependency inversion principle) _ Design pattern

Role: It guides us in how to properly resolve dependencies between modules, and it is also the core principle of framework design.

The essence of the dependency inversion principle is to require the relationship between classes to be based on an abstract interface. Robert Martin describes in this way the dependency inversion principle [Martin 1996]:

The traditional strategy is to "divide and conquer" the complex system. This is what is usually called decomposition. The SA Method (structured analysis) also uses such a decomposition strategy to break down large and complex software systems into subsystems that are easily understood and easily analyzed by people. The decomposition here is based on the logical characteristics of the software system and the logical relationship between the components within the system. In the decomposition process, the decomposition of the upper layer is the lower level of abstraction, the lower layer is the detail of the upper layer.

We try to control programming at the abstraction level, programming against the interface, not programming for implementation.

To rely on abstraction, do not rely on concrete. This means that we try to control programming in the abstraction layer, to programming for the interface, not to implement programming.

The opening and closing principle is the goal, and the means to achieve this goal is to rely on the inverted principle. The abstraction level contains the business logic of the application system and the macroscopic, the important strategic decision for the whole system is the embodiment of inevitability, then the abstract level should be more stable, should be the focal point of reuse, and should be the focus of maintenance, and the specific level contains some minor algorithms and logic related to implementation, and tactical decisions, with considerable contingency options. The specific level of code is often changed, can not avoid errors.