Dependency Inversion principle

The so-called dependency inversion principle (dependence inversion Principle) is to rely on abstraction and not rely on specifics.

The simple thing is to program the abstraction, not to program the implementation, thus reducing the coupling between the customer and the implementation module.

Process-oriented development, the upper layer calls the lower layer, the upper layer depends on the lower layer, when the lower level of drastic changes, the upper layer must follow the change, which will lead to the module reusability and greatly improve the cost of development.

Object-oriented development is a good solution to this problem, the general situation of the abstract change probability is very small, so that the user program depends on the abstraction, the implementation of the details also rely on abstraction. Even if the implementation details change, the client program does not need to change as long as the abstraction is constant.

This greatly reduces the degree of coupling of the client program domain implementation details.

For example, a joint venture car company now requires the development of an autonomous driving system that can be unmanned if the system is installed on the car, which can be used on the Ford series and the Honda Car series. Process-oriented structure diagram:

Process-oriented design:

 Public classHondacar { Public voidRun () {Console.WriteLine ("Honda Car started up!) "); }         Public voidTurn () {Console.WriteLine ("Honda's turning!") "); }         Public voidStop () {Console.WriteLine ("Honda Car stopped!") "); }    } Public classFordcar { Public voidRun () {Console.WriteLine ("The Ford car is up!) "); }         Public voidTurn () {Console.WriteLine ("Ford's turning!") "); }         Public voidStop () {Console.WriteLine ("Ford car stopped!") "); }    } Public classAutosystem { Public enumcartype{Ford,fonda}PrivateHondacar hondcar=NewHondacar (); PrivateFordcar fordcar=NewFordcar (); PrivateCartype type;  PublicAutosystem (Cartype cartype) { This. Type =Cartype; }         Public voidRuncar () {if( This. Type = =Cartype.fonda) {Hondcar.            Run (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Run (); }        }                 Public voidStopcar () {if( This. Type = =Cartype.fonda) {Hondcar.            Stop (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Stop (); }        }         Public voidTurncar () {if( This. Type = =Cartype.fonda) {Hondcar.            Turn (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Turn (); }        }    }

Obviously this implementation code can also meet the needs of today.
But how the company's business is now expanding, and the autonomous driving system will also be compatible with the Jeep. These need to be modified Autosystem class as follows:

 Public classAutosystem { Public enumcartype{Ford,fonda}PrivateHondacar hondcar=NewHondacar (); PrivateFordcar fordcar=NewFordcar (); PrivateCartype type;  PublicAutosystem (Cartype cartype) { This. Type =Cartype; }         Public voidRuncar () {if( This. Type = =Cartype.fonda) {Hondcar.            Run (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Run (); }        }                 Public voidStopcar () {if( This. Type = =Cartype.fonda) {Hondcar.            Stop (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Stop (); }            Else if( This. Type = =cartype.jeep) {Jeep.            Stop (); }        }         Public voidTurncar () {if( This. Type = =Cartype.fonda) {Hondcar.            Turn (); }            Else if( This. Type = =Cartype.ford) {Fordcar.            Turn (); }            Else if( This. Type = =cartype.jeep) {Jeep.            Turn (); }        }    }

Through the code analysis, the above code also does meet the requirements, but the software is constantly changing, the requirements of the software is also changing, if the future expansion of the business, the automatic driving system can also achieve GM, Mitsubishi, Volkswagen, so we have to change the Autosystem class again.
This causes the system to become more and more bloated, larger and more dependent on a growing number of low-level modules, only the low-level module changes, the Autosystem class will have to follow the changes, resulting in system design becomes very fragile and stiff.
One reason for the above problem is that a module that contains a high-level policy, such as a autosystem module, relies on modules (such as Fordcar and Hondacar) that it controls for specific details of the lower layers.
If you can make the Autosystem module independent of the specific details it controls, but instead rely on abstraction, then we can take it. This is the "dependency inversion" mechanism in object-oriented.

The implementation code is as follows:

 Public InterfaceICar {voidRun (); voidStop (); voidTurn (); } Public classHondacar:icar { Public voidRun () {Console.WriteLine ("Honda Car started up!) "); }         Public voidTurn () {Console.WriteLine ("Honda's turning!") "); }         Public voidStop () {Console.WriteLine ("Honda Car stopped!") "); }    } Public classFordcar:icar { Public voidRun () {Console.WriteLine ("The Ford car is up!) "); }         Public voidTurn () {Console.WriteLine ("Ford's turning!") "); }         Public voidStop () {Console.WriteLine ("Ford car stopped!") "); }    } Public classJeep:icar { Public voidRun () {Console.WriteLine ("The Ford car is up!) "); }         Public voidTurn () {Console.WriteLine ("Ford's turning!") "); }         Public voidStop () {Console.WriteLine ("Ford car stopped!") "); }    } Public classAutosystem {PrivateICar Car;  PublicAutosystem (ICar car) { This. Car =car; }                 Public voidRuncar () { This. Car.        Run (); }         Public voidStopcar () { This. Car.        Stop (); }         Public voidTurncar () { This. Car.        Turn (); }    }

Now the Autosystem system relies on the abstraction of icar, and with the specific implementation details Hondacar: It is not related to Fordcar, so the change in implementation details does not affect autosystem. For implementation details, just implement ICAR. That is, the implementation details depend on icar abstraction.
In summary: An important strategic decision in an application and the business is in these high-level modules. It is also these modules that contain the features of this application. However, when these modules rely on low-level modules, the modification of the lower-level modules will directly affect them, forcing them to change as well. This situation is absurd.
Should be a high-level module to force those low-rise modules to change. Modules at high levels should take precedence over lower-level modules. In any case, high-level modules should not be dependent on lower modules. And we want to be able to reuse a high-level module, only the high-level module independent of the lower module, reuse is possible.
In short, high-level modules should not be dependent on low levels of modules, they should all depend on abstraction. Abstractions should not be dependent on specifics, but should be dependent on abstraction.

Dependency Inversion principle