设计模式六大原则之依赖倒置原则

本文参考《设计模式之禅》一书。

依赖倒置原则（Dependence Inversion Principle,DIP）定义：

High level modules should not depend upon low level modules.Both should depend uponabstractions.Abstractions should not depend upon details.Details should depend upon abstractions。（高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。）

个人建议大家好好理解一下抽象、向上造型和依赖关系的实现方法：

抽象是对实现的约束，对依赖者而言，也是一种契约或者说是一种规范标准，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到“言必信，行必果”。

向上造型定义：父类的引用指向子类的对象。

在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型（父类）和实际类型（子类），表面类型是在定义的时候赋予的类型，实际类型是对象的类型（向上造型）。

依赖的三种实现方法：

1.构造函数传递依赖对象

在类中通过构造函数声明依赖对象（即构造方法传入参数），按照依赖注入的说法，这种方式叫做构造函数注入

2.Setter方法传递依赖对象

在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按照这种方式的注入

3.接口声明依赖对象

在接口的方法中声明依赖对象，该方法也叫做接口注入。

依赖倒置原则精简定义：“面向接口编程”——OOD（Object-Oriented Design），面向对象设计的精髓之一。

大白话就是说，当你写程序需要传入参数的时候，尽可能的使用接口。

包含三层含义：

● 高层模块不应该依赖低层模块，两者都应该依赖其抽象；

● 抽象不应该依赖细节；

● 细节应该依赖抽象。

依赖倒置原则在Java语言中的表现：

● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类。

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

什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。

我们再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用（TDD方法：引入一个JMock工具，其最基本的功能是根据抽象虚拟一个对象进行测试，想象一下所有的高层模块都是使用接口或者抽象类，测试是不是很方便，一个字“爽”；当然再想想，如果低层模块需要增加其它业务，只要实现相关接口或者继承抽象类，好处不言而喻啊）。

下面和各位说说“倒置”：

说的现在，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢？

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

实践指导：

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

在项目中使用该规则呢？只要遵循以下的几个规则就可以：

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

● 变量的表面类型尽量是接口或者是抽象类很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。

● 任何类都不应该从具体类派生如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。）

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

● 结合里氏替换原则使用在第上一篇中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章的讲解，我们可以得出这样一个通俗的规则： 

接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

依赖倒置原则的优点在小型项目中很难体现出来，例如小于10个人月的项目，使用简单的SSH架构，基本上不费太大力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则有非常多的优点，特别是规避一些非技术因素引起的问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒置原则的核心。讲了这么多依赖倒置原则的优点，我们也来打击一下大家，在现实世界中确实存在着必须依赖细节的事物，比如法律，就必须依赖细节的定义。

“杀人偿命”在中国的法律中古今有之[1]，那这里的“杀人”就是一个抽象的含义，怎么杀，杀什么人，为什么杀人，都没有定义，只要是杀人就统统得偿命，这就是有问题了，好人杀了坏人，还要陪上自己的一条性命，这是不公正的，从这一点看，我们在实际的项目中使用依赖倒置原则时需要审时度势，不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。

作为一个项目经理或架构师，应该懂得技术只是实现目的的工具，惹恼了顶头上司，设计做得再漂亮，代码写得再完美，项目做得再符合标准，一旦项目亏本，产品投入大于产出，那整体就是扯淡！你自己也别想混得更好！

希望大家细细品味吧！！！