。

简单的说就是要求对抽象进行编程#xff0c;不要对实现进行编程#xff0c;这样就降低了客户与实现模块间的耦合。

1.概念

Principle是程序要依赖于抽象接口不要依赖于具体实现。

简单的说就是要求对抽象进行编程不要对实现进行编程这样就降低了客户与实现模块间的耦合。

2.案例分析

需求我们要开发一套自动驾驶系统只要在汽车上安装该系统就可以实现自动驾驶该系统目前只支持在福特和本田车上使用。

优化前版本不满足依赖倒置原则

Run(){Console.WriteLine(福特开始启动了);}public

void

Turn(){Console.WriteLine(福特开始转弯了);}public

void

Stop(){Console.WriteLine(福特开始停车了);}}///

summary///

Run(){Console.WriteLine(本田开始启动了);}public

void

Turn(){Console.WriteLine(本田开始转弯了);}public

void

Stop(){Console.WriteLine(本田开始停车了);}}///

summary///

CarType.Ford){fcar.Run();}else{hcar.Run();}}///

summary///

CarType.Ford){fcar.Turn();}else{hcar.Turn();}}///

summary///

CarType.Ford){fcar.Stop();}else{hcar.Stop();}}public

enum

1,};}{//DIP:依赖倒置原则//福特车AutoSystem

fordAutoSystem

AutoSystem(CarType.Ford);fordAutoSystem.RunCar();fordAutoSystem.TurnCar();fordAutoSystem.StopCar();//本田车AutoSystem

hondaAutoSystem

AutoSystem(CarType.Honda);hondaAutoSystem.RunCar();hondaAutoSystem.TurnCar();hondaAutoSystem.StopCar();}

代码分析

上面的程序确实能够实现针对Ford和Honda车的无人驾驶但是在实际的生成场景中需求是不断变化的比如我们现在又增加了一个新的合作伙伴宝马车那我们就需要新定义一个宝马车的实现类以及对应的枚举CarType和上层的AutoSystem类都需要跟着修改当随着越来越多的车企加入我们那我们当前的设计就会变得僵化、脆弱。

如何优化

导致上面所述问题的一个原因是含有高层策略的utoSystem模块依赖于它所控制的低层的具体细节的模块HondaCar和FordCar。

如果我们能够找到一种方法使AutoSystem模块独立于它所控制的具体细节那么我们就可以自由地复用它了。

我们就可以用这个模块来生成其它的程序使得系统能够用在需要的汽车上。

毋庸置疑那就该我们的依赖倒置原则出场了。

///

Run(){Console.WriteLine(福特开始启动了);}public

void

Turn(){Console.WriteLine(福特开始转弯了);}public

void

Stop(){Console.WriteLine(福特开始停车了);}}///

summary///

Run(){Console.WriteLine(本田开始启动了);}public

void

Turn(){Console.WriteLine(本田开始转弯了);}public

void

Stop(){Console.WriteLine(本田开始停车了);}}///

summary///

StopCar(){icar.Stop();}}{//DIP:依赖倒置原则//福特车ICar

car

AutoSystemDIP(car);fordAutoSystem.RunCar();fordAutoSystem.TurnCar();fordAutoSystem.StopCar();//本田车car

new

AutoSystemDIP(car);hondaAutoSystem.RunCar();hondaAutoSystem.TurnCar();hondaAutoSystem.StopCar();}

代码分析

这个抽象而与具体的实现细节HondaCar、FordCar无关所以实现细节的变化不会影响AutoSystem。

对于实现细节只要实现ICar

3.优缺点

除了抽象难度大点、需要对功能业务理解透彻以外几乎无缺点依赖倒置还是我们开发中使用比较频繁的一个原则。