依赖倒置原则(DIP)原则的原始定义：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象。
- 抽象不应该依赖细节。
- 细节应该依赖抽象。
抽象指的是接口或抽象类，两者都是不能直接被实例化的。细节就是实现类。实现接口或抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字
new产生的对象。
依赖倒置原则在Java中的表现就是：
- 模块间依赖通过抽象发生，实现类之间不发生直接的依赖关系，期依赖关系是通过接口或抽象类生产的。
- 接口或抽象类不依赖于实现类。
- 实现类依赖接口或抽象类。
更加精简的定义就是“面向接口编程（OOD）”。
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
依赖的三种写法
依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D…，生生不息，依赖不止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！
- 构造函数传递依赖对象。在类中通过构造函数声明依赖对象，按照依赖注入的说法这种方式叫做构造函数注入。
- Setter方法传递依赖对象。在抽象中设置setter方法声明依赖关系，依照依赖注入的说法就是setter依赖注入。
- 接口声明依赖对象。在接口的方法中声明依赖对象，该方法也叫做接口注入。
依赖倒转原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。 - 变量的显示类型尽量是接口或者是抽象类。
很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供一个规范。 - 任何类都不应该从具体类派生。
如果一个项目处于开发状态，确实不应该有从具体类派生出的子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再要去继承最高的基类呢？ - 尽量不要覆写基类的方法。
如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。 - 结合里氏替换原则使用
父类出现的地方子类就能出现。接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
