在面向过程开发中，我们考虑的是如何实现，依赖的是每个具体实现，而在OOP中，则需要依赖每个接口，而不能依赖具体的实现，比如我们要到北京出差，应该依赖交通工具，而不是依赖的具体飞机或火车，也就是说我们依赖的是交通工具的运输能力，而不是具体的一架飞机或某一列火车。这样的依赖可以让我们实现解耦，保持代码间的松耦合，提高代码的复用率，这也是依赖倒置原则（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语言中的表现就是：
模块间的依赖是通过抽象发生的，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
接口或抽象类不依赖于实现类。
实现类依赖接口或抽象类。
更加精简的定义就是“面向接口编程”，它的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，互不影响，从而实现模块间的松耦合。那我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以。
（1）尽量抽象
每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
（2）表面类型必须是抽象的
比如定义集合，尽量使用如下这种类型：
List＜String＞list=new ArrayList＜String＞（）；
此时list的表面类型为List，是一个列表的抽象，而实际类型为ArrayList。在可能的情况下，尽量抽象表面类型，但也存在不必抽象的情况，比如工具类xxxUtils，一般是不需要接口或是抽象类的。
（3）任何类都不应该从具体类派生
如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有设计缺陷是在所难免的，因此只要是不超过两层的继承都是可以忍受的。特别是做项目维护时，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发的，修复行为通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或无法获得父类代码的情况下）。
（4）尽量不要覆写基类的方法
如果基类是一个抽象类，而且这个方法已经实现了，那么子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
（5）抽象不关注细节
接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确地实现了业务逻辑，同时在适当的时候对父类进行了细化，各司其职才能保证抽象的依赖完美实现。
依赖抽象的优点在小型项目中很难体现出来，例如在小于10个人月的项目中，使用简单的SSH架构，基本上不用费太大力气就可以完成，是否采用抽象依赖原则影响不大。但是，在一个大中型项目中，采用抽象依赖可以带来非常多的优点，特别是可以规避一些非技术因素引起的问题。项目越大，需求变化的概率也就越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果项目设计优良、代码结构清晰，人员变化对项目的影响则基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。