3 证明

采用依赖倒置原则可减少类间耦合，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

证明一个定理是否正确，有两种常用方法：

• 顺推证法
  根据论题，经过论证，推出和定理相同结论
• 反证法
  先假设提出的命题是伪命题，然后推导出一个与已知条件互斥结论

反证法来证明依赖倒置原则的优秀！

论题

依赖倒置原则可减少类间的耦合性，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

反论题

不使用依赖倒置原则也可减少类间的耦合性，提高系统稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

通过一个例子来说明反论题不成立！

• 司机驾驶奔驰车类图

奔驰车可提供一个方法run，代表车辆运行：

司机通过调用奔驰车的run方法开动奔驰车

有车，有司机，在Client场景类产生相应的对象

现在来了新需求：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？

走一步是一步，先把宝马车产生出来

宝马车产生了，但却没有办法让张三开起来，为什么？

张三没有开动宝马车的方法呀！一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象。

我们的设计出现了问题：司机类和奔驰车类紧耦合，导致系统可维护性大大降低，可读性降低。

两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。

被依赖者的变更竟然让依赖者来承担修改成本，这样的依赖关系谁肯承担？

证明至此，反论题已经部分不成立了。

继续证明，“减少并行开发引起的风险”

什么是并行开发的风险？

并行开发最大的风险就是风险扩散，本来只是一段程序的异常，逐步波及一个功能甚至模块到整个项目。一个团队，一二十个开发人员，各人负责不同功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有开发工作都是“单线程”，甲做完，乙再做，然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队协作的结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？

依赖倒置原则隆重出场！

根据以上证明，若不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和可维护性。

引入DIP后的UML：

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法

接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成

IDriver通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要声明在高层模块。

ICar及其两个实现类的实现过程：

业务场景应贯彻“抽象不应依赖细节”，即抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用都是抽象：

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，java的表面类型是IDriver，Benz的表面类型是ICar。

在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？

java的表面类型是IDriver，是一个接口，是抽象的、非实体化的，在其后的所有操作中，java都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，java如果要开宝马车，也很容易，只需修改业务场景类即可。

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

Java只要定义变量就必然要有类型，一个变量可以有两种类型：

表面类型

在定义的时候赋予的类型

实际类型

对象的类型，如java的表面类型是IDriver，实际类型是Driver。

思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）即可独立开发，而且项目之间的单元测试也可以独立地运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。

回顾司机驾驶汽车的例子：

甲程序员负责IDriver开发

乙程序员负责ICar的开发

两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快，完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？

根据抽象虚拟一个对象进行测试：

只需要一个ICar接口，即可对Driver类进行单元测试。

这点来看，两个相互依赖的对象可分别进行开发，各自独立进行单元测试，保证了并行开发的效率和质量，TDD开发的精髓不就在这？

TDD，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目或在项目成员整体水平较低情况下采用。

抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其为保证所有细节不脱离契约范畴，确保约束双方按既定契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈。