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.抽象不应该依赖细节；细节应该依赖抽象

针对接口编程，不要针对实现编程。

每个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的
细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。
依赖倒置原则在Java语言中的表现就是：
● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
● 接口或抽象类不依赖于实现类；
● 实现类依赖接口或抽象类。

优点：可以减少类间的耦合性、提高系统稳定性，提高代码可读性和可维护性，可降低修改程序所造成的风险。

能不能把依赖弄对，要动点脑。依赖关系没处理好，就会导致一个小改动影响一大片。
把依赖方向搞反，就是最典型错误。

最重要的是要理解“倒置”，而要理解什么是“倒置”，就要先理解所谓的“正常依赖”是什么样的。
结构化编程思路是自上而下功能分解，这思路很自然地就会延续到很多人的编程习惯。按照分解结果，进行组合。所以，很自然地写出下面这种代码

这种结构天然的问题：高层模块依赖于低层模块：

• CriticalFeature是高层类
• Step1和Step2就是低层模块，而且Step1和Step2通常都是具体类

很多人好奇了：step1和step2如果是接口，还有问题吗？像这种流程式的代码还挺常见的?
有问题，你无法确定真的是Step1和Step2，还会不会有Step3，所以这个设计依旧是不好的。如果你的设计是多个Step，这也许是个更好的设计。

在实际项目中，代码经常会直接耦合在具体的实现上。比如，我们用Kafka做消息传递，就在代码里直接创建了一个KafkaProducer去发送消息。我们就可能会写出这样的代码：

我用Kafka发消息，创建个KafkaProducer，有什么问题吗？
我们需要站在长期角度去看，什么东西是变的、什么东西是不变的。Kafka虽然很好，但它并不是系统最核心部分，未来是可能被换掉的。

你可能想，这可是我的关键组件，怎么可能会换掉它？
软件设计需要关注长期、放眼长期，所有那些不在自己掌控之内的东西，都有可能被替换。替换一个中间件是经常发生的。所以，依赖于一个可能会变的东西，从设计的角度看，并不是一个好的做法。

那该怎么做呢？这就轮到倒置了。

倒置，就是把这种习惯性的做法倒过来，让高层模块不再依赖低层模块。
功能该如何完成？

计算机科学中的所有问题都可以通过引入一个间接层得到解决。 All problems in computer science can be
solved by another level of indirection —— David Wheeler

引入一个间接层，即DIP里的抽象，软件设计中也叫模型。这段代码缺少了一个模型，而这个模型就是这个低层模块在这个过程中所承担角色。

2 实战

重构

既然这个模块扮演的就是消息发送者的角色，那我们就可以引入一个消息发送者（MessageSender）的模型：

有了消息发送者这个模型，又该如何把Kafka和这个模型结合呢？
实现一个Kafka的消息发送者：

这样高层模块就不像之前直接依赖低层模块，而是将依赖关系“倒置”，让低层模块去依赖由高层定义好的接口。
好处就是解耦高层模块和低层实现。

若日后替换Kafka，只需重写一个MessageSender，其他部分无需修改。这就能让高层模块保持稳定，不会随低层代码改变。

这就是建立模型（抽象）的意义。

所有软件设计原则都在强调尽可能分离变的部分和不变的部分，让不变的部分保持稳定。
模型都是相对稳定的，而实现细节是易变的。所以，构建稳定的模型层是关键。

依赖于抽象

抽象不应依赖于细节，细节应依赖于抽象。

简单理解：依赖于抽象，可推出具体编码指导：

• 任何变量都不应该指向一个具体类
  如最常用的List声明

• 任何类都不应继承自具体类

• 任何方法都不应该改写父类中已经实现的方法

当然了，如上指导并非绝对。若一个类特稳定，也可直接用，比如String 类，但这种情况很少！
因为大多数人写的代码稳定度都没人家 String 类设计的高。

学习

首先定义一个学习者类

简单的测试类

假如现在又想学习Python，则面向实现编程就是直接在类添加方法

此类需经常改变，扩展性太差，Test 高层模块, Learner 类为低层模块，耦合度过高！

让我们引入抽象：

现在就能将原学习者类的方法都消除

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

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

4 依赖

依赖可以传递，A对象依赖B对象，B又依赖C，C又依赖D……
只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！

对象的依赖关系有如下传递方式：

构造器传递

在类中通过构造器声明依赖对象，构造函数注入

4.2 Setter传递

在抽象中设置Setter方法声明依赖关系,Setter依赖注入

4.3 接口声明依赖对象

在接口的方法中声明依赖对象

5 最佳实践

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。

DIP指导下，具体类能少用就少用。
具体类我们还是要用的，毕竟代码要运行起来不能只依赖于接口。那具体类应该在哪用？
这些设计原则，核心关注点都是一个个业务模型。此外，还有一些代码做的工作是负责组装这些模型，这些负责组装的代码就需要用到一个个具体类。

做这些组装工作的就是DI容器。因为这些组装几乎是标准化且繁琐。如果你常用的语言中，没有提供DI容器，最好还是把负责组装的代码和业务模型放到不同代码。

DI容器另外一个说法叫IoC容器，Inversion of Control，你会看到IoC和DIP中的I都是inversion，二者意图是一致的。

依赖之所以可注入，是因为我们的设计遵循 DIP。而只知道DI容器不了解DIP，时常会出现让你觉得很为难的模型组装，根因在于设计没做好。

DIP还称为好莱坞规则：“Don’t call us, we’ll call you”，“别调用我，我会调你的”。这是框架才会有的说法，有了一个稳定抽象，各种具体实现都应由框架去调用。

为什么说一开始TransactionRequest是把依赖方向搞反了？因为最初的TransactionRequest是一个具体类，而TransactionHandler是业务类。

我们后来改进的版本里引入一个模型，把TransactionRequest变成了接口，ActualTransactionRequest 实现这个接口，TransactionHandler只依赖于接口，而原来的具体类从这个接口继承而来，相对来说，比原来的版本好一些。

对于任何一个项目而言，了解不同模块的依赖关系是一件很重要的事。你可以去找一些工具去生成项目的依赖关系图，然后，你就可以用DIP作为一个评判标准，去衡量一下你的项目在依赖关系上表现得到底怎么样了。很有可能，你就找到了项目改造的一些着力点。

理解了 DIP，再来看一些关于依赖的讨论，我们也可以看到不同的角度。
比如，循环依赖，循环依赖就是设计没做好的结果，把依赖关系弄错，才可能循环依赖，先把设计做对，把该有的接口提出来，就不会循环了。

我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：

• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
  这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置

• 变量的表面类型尽量是接口或者是抽象类
  很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了

  • 比如一个工具类，xxxUtils一般是不需要接口或是抽象类的
  • 如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。

• 任何类都不应该从具体类派生
  如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的

• 尽量不要覆写基类方法
  如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写
  类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响

• 结合里氏替换原则使用
  父类出现的地方子类就能出现， 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

到底什么是“倒置”

依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑。
而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的

依赖倒置原则是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。
只要记住面向接口编程就基本上抓住了依赖倒置原则的核心。

依赖倒置原则说的是：
1.高层模块不应依赖于低层模块，二者都应依赖于抽象
2.抽象不应依赖于细节，细节应依赖于抽象
总结起来就是依赖抽象（模型），具体实现抽象接口，然后把模型代码和组装代码分开，这样的设计就是分离关注点，将不变的与不变有效的区分开

防腐层可以解耦对外部系统的依赖。包括接口和参数。防腐层还可以贯彻接口隔离的思想，以及做一些功能增强(加缓存,异步并发取值)。

参考

• 设计模式之婵

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/117418515