依赖倒置原则

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，
不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几
个规则就可以：
● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
● 变量的表面类型尽量是接口或者是抽象类
很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具
类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须
使用实现类，这个是JDK提供的一个规范。
● 任何类都不应该从具体类派生
如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝
对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都
是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么？维护工
作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个
很大的Bug，何必去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或者无法
获得父类代码的情况下。）
● 尽量不要覆写基类的方法
如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是
抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
● 结合里氏替换原则使用
在第2章中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章的讲
解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他
对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适
当的时候对父类进行细化。
讲了这么多，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢？我们
先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面
向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑
就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是
有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思
维中的事物间的依赖，“倒置”就是从这里产生的。
依赖倒置原则的优点在小型项目中很难体现出来，例如小于10个人月的项目，使用简单
的SSH架构，基本上不费太大力气就可以完成，是否采用依赖倒置原则影响不大。但是，在
一个大中型项目中，采用依赖倒置原则有非常多的优点，特别是规避一些非技术因素引起的
问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实
现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也
是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项
目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。
依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依
赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住
是“面向接口编程”就基本上抓住了依赖倒置原则的核心。
讲了这么多依赖倒置原则的优点，我们也来打击一下大家，在现实世界中确实存在着必
须依赖细节的事物，比如法律，就必须依赖细节的定义。“杀人偿命”在中国的法律中古今有
之[1]，那这里的“杀人”就是一个抽象的含义，怎么杀，杀什么人，为什么杀人，都没有定
义，只要是杀人就统统得偿命，这就是有问题了，好人杀了坏人，还要陪上自己的一条性
命，这是不公正的，从这一点看，我们在实际的项目中使用依赖倒置原则时需要审时度势，
不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，
所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。作为一个项目经
理或架构师，应该懂得技术只是实现目的的工具，惹恼了顶头上司，设计做得再漂亮，代码
写得再完美，项目做得再符合标准，一旦项目亏本，产品投入大于产出，那整体就是扯淡！
你自己也别想混得更好！