一、依赖倒置原则定义
依赖倒置原则（Dependence Inversion Principle,DIP）的官方定义如下：
1、High level modules should not depend upon low level modules.（高层模块不应该依赖低层模块）
2、Both should depend upon abstractions.（两者都应该依赖于抽象）
3、Abstractions should not depend upon details.（抽象不应该依赖细节）
4、Details should depend upon abstractions.（细节应该依赖抽象）
解释一下上面这几句话：
高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。
那什么是抽象？什么又是细节呢？
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。
依赖倒置原则在Java语言中的表现就是：
1、模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
2、接口或抽象类不依赖于实现类；
3、实现类依赖接口或抽象类。
更加精简的定义就是“ 面向接口编程 ”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。
依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构要比以细节为基础的架构稳定的多，在Java中，抽象指的是接口或抽象类，细节指具体的实现类，即要求程序要依赖于抽象接口，不要依赖于具体实现
说了这么多，这个“倒置”该如何理解？
我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。
二、一个案例
1、司机驾驶奔驰车
某司机驾驶了一辆奔驰车，类图如下
司机类如下
public class Driver {
//司机的主要职责就是驾驶汽车
public void drive(Benz benz){
benz.run();
}
}
奔驰车类如下
public class Benz {
//汽车肯定会跑
public void run(){
System.out.println("奔驰汽车开始运行...");
}
}
启动类如下
public class Client {
public static void main(String[] args) {
Driver zhangSan = new Driver();
Benz benz = new Benz();
//张三开奔驰车
zhangSan.drive(benz);
}
}
通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题
2、司机要开宝马车
现在有个需求：司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢
首先，先定义一个宝马车
public class BMW {
//宝马车当然也可以开动了
public void run(){
System.out.println("宝马汽车开始运行...");
}
}
但是，司机开不了，因为司机的驾驶方法传参只能传奔驰车。。。很明显，我们的设计出现了问题：司机类和奔驰车类之间是紧耦合的关系，其导致的结果就是系统的可维护性大大降低
这里引入依赖倒置原则解决该问题，引入之后的类图如下
司机相关类如下：
public interface IDriver {
//是司机就应该会驾驶汽车
public void drive(ICar car);
}
public class Driver implements IDriver{
//司机的主要职责就是驾驶汽车
public void drive(ICar car){
car.run();
}
}
汽车相关类如下：
public interface ICar {
//是汽车就应该能跑
public void run();
}
//奔驰汽车定义
public class Benz implements ICar{
//汽车肯定会跑
public void run(){
System.out.println("奔驰汽车开始运行...");
}
}
//宝马汽车定义
public class BMW implements ICar{
//宝马车当然也可以开动了
public void run(){
System.out.println("宝马汽车开始运行...");
}
}
这时候想开奔驰，这样做
public class Client {
public static void main(String[] args) {
IDriver zhangSan = new Driver();
ICar benz = new Benz();
//张三开奔驰车
zhangSan.drive(benz);
}
}
如果想开宝马，这样做即可
public class Client {
public static void main(String[] args) {
IDriver zhangSan = new Driver();
ICar bmw = new BMW();
//张三开宝马车
zhangSan.drive(bmw);
}
}
Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的表面类型是IDriver，Benz的表面类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的表面类型是IDriver，是一个接口，是抽象的、非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。
三、依赖的三种写法
依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D……生生不息，依赖不止。
对象的依赖关系有三种方式来传递：构造函数传递、Setter方法传递、接口声明依赖对象。
1、构造函数依赖
在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入，按照这种方式的注入，IDriver和Driver的程序修改后如下所示
public interface IDriver {
//是司机就应该会驾驶汽车
public void drive();
}
public class Driver implements IDriver{
private ICar car;
//构造函数注入
public Driver(ICar _car){
this.car = _car;
}
//司机的主要职责就是驾驶汽车
public void drive(){
this.car.run();
}
}
2、Setter方法传递依赖对象
按照这种方式的注入，IDriver和Driver的程序修改后如下所示
public interface IDriver {
//车辆型号
public void setCar(ICar car);
//是司机就应该会驾驶汽车
public void drive();
}
public class Driver implements IDriver{
private ICar car;
public void setCar(ICar car){
this.car = car;
}
//司机的主要职责就是驾驶汽车
public void drive(){
this.car.run();
}
}
3、接口声明依赖对象
上面章节的案例就是使用的这种方式声明依赖对象的，它直接在接口方法上传参。
public interface IDriver {
//是司机就应该会驾驶汽车
public void drive(ICar car);
}
public class Driver implements IDriver{
//司机的主要职责就是驾驶汽车
public void drive(ICar car){
car.run();
}
}
四、最佳实践
依赖倒置原则的核心就是面向抽象(抽象类或者接口)编程，以抽象为基准搭建起来的架构比以细节为基准搭建的架构要稳定的多，因此，在拿到需求之后，要先顶层再细节的方式来进行代码设计，这样各个类或模块的实现彼此独立，不互相影响，实现了模块间的松耦合。
那么，如何应用这个规则呢，遵循以下几个规则：
1、每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。 这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象 才可能依赖倒置。
2、变量的表面类型尽量是接口或者是抽象类。 很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。
3、任何类都不应该从具体类派生。 这个要看具体情况而定，如果通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必去继承最高的基类呢
4、尽量不要覆写基类的方法。 如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
5、结合里氏替换原则使用。
以上几个原则比较少生硬，在使用的时候稍加注意即可，不可生搬硬套。
参考文档：
《设计模式之禅（第2版）》第3章《依赖倒置原则》
注意：本文归作者所有，未经作者允许，不得转载