定义

依赖倒置原则（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
翻译一下：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

进一步的理解

到底什么“倒置”，要理解什么是倒置，我们先理解一下“正置”，即正常的依赖是什么样子的。比如我们经典的三层架构，controller层调用BL层，BL层调用DAO层。由于每一层都是依赖于下层的实现，这样当某一层的结构发生变化时，它的上层就不得不也要发生改变，比如我们DAO里面逻辑发生了变化，可能会导致BL和Controller层都随之发生变化，这种架构是非常荒谬的！

好，这个时候如果我们换一种设计思路，高层模块不直接依赖低层的实现，而是依赖于低层模块的抽象，具体表现为我们增加一个IBL层，里面定义业务逻辑的接口，controller层依赖于IBL层，BL层实现IBL里面的接口，所有具体的业务逻辑则实现在BL里面，这个时候如果我们BL里面的逻辑发生变化，只要接口的行为不变，上层Controller里面就不用发生任何变化。

以上我们引入面向接口编程的概念，增加了接口IBL层，那倒置到底该如何理解，难道依赖抽象，面向接口就是倒置了？

我觉得可以从软件项目越来越大，开发团队人员越来越多的发展现状来理解，高层A依赖于低层B，即A要调用B提供的方法，那么在B开发完成之前，A层是没发开发，或者开发完没法编译通过和单元测试的。修改为高层A依赖于抽象层C，抽象层C是属于A层的，即由A层来规定抽象层C的接口规范，低层B也依赖于抽象层C来具体实现C中的接口，因此通过引入C层，来达到了“倒置”。通过该倒置，引入C层来规范，A和B 可以同时 来开发，不必相互等待（依赖）。这里的倒置，既有模块依赖上的倒置，更有在解决问题时，思考和规划上的倒置，即要先进行良好的顶层规划设计，约定好接口规范，而具体的逻辑编写都是基于规范的具体而已。

作用

• 可以减少类间的耦合性、提高系统稳定性。
• 提高代码可读性和可维护性，可降低修改程序所造成的风险。
• 可以减少并行开发引起的风险。

实现方法

主要就是合理的抽象接口类并定义接口方法。以下代码示例中以 司机驾车为例，结合代码重构过程来具体说明。

代码示例

司机驾驶奔驰车的类图，起初 我们设计的都是具体实现类，司机类依赖于奔驰车类，Client类中有司机，有车，可以具体创建对象来使用了。

package com.will.tools.model.dip;
 
public class Benz {
 
    public void run(){
        System.out.println("奔驰汽车跑起来...");
    }
}

奔驰车可提供一个方法run，代表车辆运行。

package com.will.tools.model.dip;
 
public class Driver {
    public void drive(Benz benz){
        benz.run();
    }
}

开车，调用奔驰车的run方法。

package com.will.tools.model.dip;
 
public class Client {
    public static void main(String[] args) {
        Driver guojing = new Driver();
        Benz benz = new Benz();
        //郭靖开奔驰
        guojing.drive(benz);
    }
}

Client创建 司机郭靖和奔驰车，并让郭靖开奔驰车。

现在来了新需求：郭靖司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？

先把宝马车创建出来，如下

package com.will.tools.model.dip;

public class BMW {
    public void run(){
        System.out.println("宝马汽车跑起来...");
    }
}

宝马车产生了，但郭靖却没有办法开起来，为什么？
郭靖（Driver）没有开动宝马车的方法，一个拿有C1驾照的司机竟然只能开奔驰车而不能开宝马车，这太不合理了！在现实世界都不允许这样干，何况程序还是对现实世界的抽象呢。

这说明我们的设计出了问题，司机类和奔驰车类紧耦合了，导致系统可维护性和可读性降低。这里只是增加了一个车类，却要修改司机类，被依赖者变更了，却需要让依赖者来承担修改成本，这没有稳定性可言。

另外，对于并行开发的风险也很大，没有奔驰车类，司机类根本编译不过去。
因此，我们重构一下，引入DIP，如下：

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法。汽车就是能run。

package com.will.tools.model.dip;
 
public interface ICar {
    void run();
}

package com.will.tools.model.dip;
 
public interface IDriver {
    void drive(ICar car);
}

package com.will.tools.model.dip;
 
public class Driver implements IDriver {
    @Override
    public void drive(ICar car) {
        car.run();
    }
}

接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成。

IDriver通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要声明在高层模块。

宝马汽车和奔驰汽车都实现ICar接口，并各自实现run方法。

package com.will.tools.model.dip;
 
public class Benz implements ICar {
 
    @Override
    public void run() {
        System.out.println("奔驰汽车跑起来...");
    }
}

package com.will.tools.model.dip;
 
public class BMW implements ICar {
    @Override
    public void run() {
        System.out.println("宝马汽车跑起来...");
    }
}

业务场景应贯彻“抽象不应依赖细节”，即抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用的都是抽象,传入的参数都是ICar,如下：

package com.will.tools.model.dip;
 
public class Client {
    public static void main(String[] args) {
//        Driver guojing = new Driver();
//        Benz benz = new Benz();
//        //郭靖开奔驰
//        guojing.drive(benz);
        IDriver guojing = new Driver();
        ICar benz = new Benz();
        guojing.drive(benz);
 
        ICar bmw = new BMW();
        guojing.drive(bmw);
    }
}

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上。guojing的表面类型是IDriver，benz的表面类型是ICar。这时，guojing再要开宝马车的话，就只需要在高层业务类（Client）中直接调用即可，而不用修改Driver类。