设计模式六大原则之--依赖倒置原则（DIP）

1. 依赖倒置原则，(Dependence Inversion Principle, DIP )

定义：High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.(高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。)

2.理解：

低层模块：不可分割的原子逻辑；

高层模块：低层模块的再组合；

抽象：   接口或抽象类（特点：不能直接被实例化）；

细节：   与接口或抽象类对应的实现类（特点：可以直拉被实例化）；

据此，DIP在Java语言中的表现就是：

1. 模块间的依赖通过抽象类或接口发生，实现类之间的依赖关系也是通过抽象类或接口产生（实现类之间不应发生直接的依赖关系）；
2. 接口或抽象不依赖于实现类，但实现类依赖接口或抽象类；

再次理解DIP：

依赖倒置原则 要求"高层模块不应该依赖于低层模块，二者都应该依赖于抽象。"这一原则在分层架构模式中，得到了淋漓尽致地运用。例如，业务逻辑层（高层模块）的对象就不应该直接依赖于数据访问层（低层模块）的具体实现对象，而应该通过数据访问层的抽象接口进行访问，如下图所示。如果高层模块直接依赖于低层模块，一旦低层模块发生变化，就会影响到高层模块。通过引入抽象，对于高层模块而言，低层模块的实现是可替换的。这实际上也是"开放封闭原则"的体现。这一原则同时还体现了软件设计对"间接"的追求。下图中的数据访问抽象层就是在设计中引入的一层间接性。

依赖倒置原则还要求"抽象不应该依赖于细节，细节应该依赖于抽象"。这与之前的要求一脉相承。关键仍然是"抽象"，抽象属于高层，细节属于低层，低层依赖于高层，而不是高层依赖于低层，这正是依赖倒置的真谛。依赖倒置原则与"面向接口编程"的思想不谋而合。GOF在《设计模式》一书中旗帜鲜明地提出了面向对象设计的首要原则，那就是"针对接口编程，而不是针对实现编程"。因为客户程序关心的仅仅是对象提供什么功能，而不是功能如何实现，甚至不关心对象的具体类型。这就好像电源插头只关心插座是两相还是三相，而无需知道插头如何与插座内的电线相连。

什么是依赖“正置”、“反置”？

依赖正置：类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程。这也是正常人的思维方式，比如要开奔驰就开奔驰（而没考虑宝马），

依赖倒置：编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”便由此而生。

3.问题由来：

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。[解决方案]将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

4.使用DIP的好处：

• 可以通过抽象使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合（也是本质）；
• 可以规避一些非技术因素引起的问题（如项目大时，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增情况。同时，发生人员变动，只要文档完善，也可让维护人员轻松地扩展和维护）；
• 可以促进并行开发（如，两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD开发模式更是DIP的最高级应用（特别适合项目人员整体水平较低时使用））。

5.难点：

• DIP是6大原则中最难以实现的原则，它是实现开闭原则的重要途径，DIP没有实现，就别想实现对扩展开放，对修改关闭。在项目中只要记住“面向接口编程”就基本上抓住了DIP的核心。
• 使用此原则时要审时度势，每个原则的优点都是有限度的，所以别为一个原则而放弃了终极目标：投产上线和盈利。

6.实践建议：

• 每个类尽量都有接口或抽象类，或者二者都有；（有了抽象才可能DIP）
  
• 变量的表面尽量是接口或抽象类；（工具类一般不需要）
  

• 任何类都不应该从具体类派生；（如果项目处于开发状态，就不应该有这种情况，当然，设计缺陷在所难免，因此不要超过两层的继承。但对于项目维护者来说，可以不用考虑这个规则，因为维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的bug，何必去继承最高的基类呢？（当然不应该轻易继承，之所以要这样，是因为可能不甚了解父类或者无法获得父类的代码））

7依赖的三种写法：

依赖是可以传递的，只要做到抽象依赖，即使是多层的依赖传递也无所畏惧。

A。构造函数传递依赖对象

[java] view plain copy

1. public interface IDriver{  
2.     //是司机就应该会驾驶汽车  
3.     public void drive();  
4. }  
5.   
6. public class Driver implements IDriver{  
7.     private ICar car;  
8.     //构造函数注入  
9.     public Driver(ICar _car){  
10.         this.car = _car;  
11.     }     
12.     //司机的主要职责就是驾驶汽车  
13.     public void drive(){  
14.         this.car.run();  
15.     }  
16. }  

B。Setter方法传递依赖对象

[java] view plain copy

1. public interface IDriver {  
2.     //车辆型号  
3.     public void setCar(ICar car);  
4.     //是司机就应该会驾驶汽车  
5.     public void drive();  
6. }  
7.   
8. public class Driver implements IDriver{  
9.     private ICar car;  
10.     public void setCar(ICar car){  
11.         this.car = car;  
12.     }  
13.     //司机的主要职责就是驾驶汽车  
14.     public void drive(){  
15.         this.car.run();  
16.     }  
17. }  

C。接口声明依赖对象

[java] view plain copy

1. public interface IDriver{  
2.     //是司机就应该会驾驶汽车  
3.     public void drive(ICar car);  
4. }  
5.   
6. public class Driver implements IDriver{  
7.     //司机的主要职责就是驾驶汽车  
8.     public void drive(ICar car){  
9.         car.run();  
10.     }  
11. }  

8.范例：

8.1 面对实现编程（当然，这里为了展现出问题，当然最小需求时，可以这样。。。）

司机驾驶奔驰车类图

[java] view plain copy

1. //司机源代码  
2. public class Driver{  
3.     //是司机就应该会驾驶汽车  
4.     public void drive(Benz benz){//1  
5.         benz.run();  
6.     }  
7. }  
8. //奔驰源代码  
9. public class Benz{  
10.     //汽车肯定会跑  
11.     public void run(){  
12.         System.out.println("奔驰汽车开始运行。。。");  
13.     }  
14. }  
15. //场景类源代码  
16. public class Client{  
17.     public static void main(String[] args){  
18.         Driver zhangsan = new Driver();  
19.         Benz benz = new Benz();//2  
20.         //张三开奔驰车  
21.         zhangsan.drive(benz);  
22.     }  
23. }  

但假若现在给出宝马类，发生变更呢？

[java] view plain copy

1. //宝马车源代码  
2. public class BMW{  
3.     //汽车肯定会跑  
4.     public void run(){  
5.         System.out.println("宝马汽车开始运行。。。");  
6.     }  
7. }  

看看，宝马有了，却不能让张三开起来，这也太不合理了，我们的设计出了问题：司机类和奔驰类之间是 紧耦合 的关系，其导致的结果就是系统的可维护性大降低，可读性降低。//若需要改为开宝马，必须得更改上述标注的 第1（低层模块，太不应该）、2（高层模块，业务变化，应该略做更改，正常） 处才可以。

8.2 现根据DIP原则，重新编写如下：

引入DIP后的类图

下面建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入ICar接口，至于到底是哪个类型号的Car，需要在高层模块中声明或修正。

[java] view plain copy

1. public interface IDriver{  
2.     //是司机就应该会驾驶汽车  
3.     public void drive(ICar car);  
4. }  
5.   
6. public class Driver implements IDriver{  
7.     //司机的主要职责就是驾驶汽车  
8.     public void drive(ICar car){  
9.         car.run();  
10.     }  
11. }  
12.   
13. public interface ICar{  
14.     //是汽车就应该能跑  
15.     public void run();  
16. }  
17.   
18.   
19. //奔驰源代码  
20. public class Benz implements ICar{  
21.     //汽车肯定会跑  
22.     public void run(){  
23.         System.out.println("奔驰汽车开始运行。。。");  
24.     }  
25. }  
26.   
27. //宝马车源代码  
28. public class BMW implements ICar{  
29.     //汽车肯定会跑  
30.     public void run(){  
31.         System.out.println("宝马汽车开始运行。。。");  
32.     }  
33. }  
34.   
35. //场景类源代码  
36. public class Client{  
37.     public static void main(String[] args){  
38.         Driver zhangsan = new Driver();  
39.         Benz benz = new Benz();//可更改这里  
40.         //张三开奔驰车  
41.         zhangsan.drive(benz);//可更改这里  
42.     }  
43. }     

若为宝马了，只需在高层模块进行变换（上述浅兰标注），代码如下：

[java] view plain copy

1. //场景类源代码  
2. public class Client{  
3.     public static void main(String[] args){  
4.         Driver zhangsan = new Driver();  
5.             BWM bwm = new BWM();  
6.         //张三开宝马  
7.         zhangsan.drive(bwm);  
8.     }  
9. }     

这样，在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要任何修改，业务就可以运行，
把变更引起的风险降低到最小。


8.3  再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD(Test-Driven Development,测试驱动开发)开发模式就是DIP的最高级应用。
回顾上述例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口，就可以独立地开发了，甲开发进度比较快， 完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？可以，我们引入一个JMock工具，其最基本的功能就是根据抽象虚拟一个对象进行测试，测试类如下所示：

[java] view plain copy

1. //测试类  
2. public class DriverTest extends TestCase{  
3.     Mockery context = new JUnit4Mockey();  
4.     @Test  
5.     public void testDriver(){  
6.         //根据接口虚拟一个对象  
7.         final ICar car = context.mock(ICar.class);  
8.         IDriver driver = new Driver();  
9.         //内部类  
10.         context.checking(new Expectations()){  
11.             oneOf(car).run();  
12.         });  
13.         driver.drive(car);  
14.     }  
15. }