依赖倒置原则-白红宇

依赖倒置原则

阅读量：6554 次

发布时间：2019-06-24

本文共 6153 字，大约阅读时间需要 20 分钟。

依赖倒置原则的定义

依赖倒置原则（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语言中的表现就是：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

接口或抽象类不依赖于实现类；

实现类依赖接口或抽象类。

更精简的定义就是“面向接口编程”——OOD（Object-Oriented Design,面向对象设计）的精髓之一。

言而无信，你太需要契约

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

证明一个定理是否正确，有两种常用的方法：一种是根据提出的论题，经过一番论证，推出和定理相同的结论，这是顺推证法；还有一种是首先假设提出的命题是伪命题，然后推导出一个荒谬、与已知条件互斥的结论，这是反证法。我们今天就用反证法来证明依赖倒置原则是多么地优秀和伟大！

论题：依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

反论题：不使用依赖倒置原则也可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

我们通过一个例子来说明反论题是不成立的。下图构造一个司机驾驶奔驰车的类图：

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

代码清单1：Driver.java （司机）

/** * * @author Barudisshu */public class Driver {        //司机的主要职责就是驾驶汽车    public void drive(Benz benz){        benz.run();    }}

司机通过调用奔驰车的run方法开动奔驰车。

代码清单2：Benz.java （奔驰）

/** * * @author Barudisshu */class Benz {        //汽车肯定会跑    public void run(){        System.out.println("奔驰汽车开始运行...");    }}

构造场景类。

代码清单3：Client.java

/** * * @author Barudisshu */public class Client {    public static void main(String[] args) {        //分别构建汽车和司机        Driver zhangSan = new Driver();        Benz benz = new Benz();        //张三驾驶奔驰汽车        zhangSan.drive(benz);    }}

现在问题来了，司机张三不仅可以开奔驰，还可以开宝马，我们构造一个宝马车类。

代码清单4：BMW.java （宝马）

public class BMW {    //宝马当然也可以开动    public void run() {        System.out.println("宝马汽车开始运行...");    }}

宝马也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法呀！奔驰和宝马同属于小车，能开奔驰不会开宝马那也太不合理了！我们的设计出了问题：司机类和奔驰类之间是紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖着的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担！证明到这里，我们已经知道反论题已经部分不成立了。

设计是否具备稳定性，只要适当“松松土”，观察“设计的蓝图”是否可以茁壮地成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。

我们继续证明，“减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏整个项目。为什么并行开发就有这样的风险呢？在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作。但是现在的大中型项目个人已经不能胜任，一个项目是一个团队协作的结果，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系。

根据以上证明，不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发的风险，降低代码的可读性和可维护性。承接上面的例子，引入依赖倒置原则：

建立两个接口，分别定义司机和汽车的各项职能。

代码清单5：IDriver.java （司机接口）

/** * * @author Barudisshu */public interface IDriver {    /**     * 是司机就应该会驾驶汽车     */    public void drive(ICar car);}

代码清单6：ICar.java （汽车接口）

/** * * @author Barudisshu */public interface ICar {    /**     * 是汽车就应该能跑     */    public void run();}

代码清单7：Driver.java （司机实现类）

/** * * @author Barudisshu */public class Driver implements IDriver{        /**司机的主要职责就是驾驶汽车*/    @Override    public void drive(ICar car) {        car.run();    }    }

代码清单8：Benz.java （奔驰实现类）

/** * * @author Barudisshu */public class Benz implements ICar{    @Override    public void run() {        System.out.println("奔驰汽车开始运行...");    }    }

代码清单9：BMW.java （宝马实现类）

/** * * @author Barudisshu */public class BMW implements ICar{    @Override    public void run() {        System.out.println("宝马汽车开始运行...");    }    }

代码清单10：Client.java （场景模拟）

/** * * @author Barudisshu */public class Client {    public static void main(String[] args) {        IDriver zhangSan = new Driver();        ICar benz = new Benz();        ICar bmw = new BMW();        //张三开奔驰        zhangSan.drive(benz);    }}

在Java中，只要定义变量就必然有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型。

我们再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行,而TDD（Test-Drivern Development,测试驱动开发）开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快,完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？答案是可以的，我们引入一个JMock工具，其最基本的功能是根据抽象虚拟一个对象进行测试，测试类代码如下：

代码清单11：DriverTest.java （测试类）

import dip.section2.Driver;import dip.section2.ICar;import dip.section2.IDriver;import junit.framework.TestCase;import org.jmock.Expectations;import org.jmock.Mockery;import org.jmock.integration.junit4.JUnit4Mockery;/** * * @author Barudisshu */public class DriverTest extends TestCase {    Mockery context = new JUnit4Mockery();    public void testDriver() {        //根据接口虚拟一个对象        final ICar car = context.mock(ICar.class);        IDriver driver = new Driver();        //内部类        context.checking(new Expectations() {            {                oneOf(car).run();            }        });        driver.drive(car);    }}

测试通过。我们只需要一个ICar的接口，就可以对Driver类进行单元测试。从这一点来看，两个互相依赖的对象可以分别进行开发，孤立地进行单元测试，进而保证并行开发的效率和质量，TDD开发的精髓不就在这里吗？测试驱动开发，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目获在项目成员整体水平比较低的情况下采用。

抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到“言必信，行必果”。

依赖的三种写法

对象的依赖关系有三种方式来传递。

1. 构造函数传递依赖对象

在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫构造函数注入，按照这种方式的注入，IDriver和Driver的程序修改后如下：

代码清单12：IDriver.java

public interface IDriver {        //是司机就应该会驾驶汽车    public void drive();}

代码清单13：Driver.java

public class Driver implements IDriver {    private ICar car;    //构造函数注入    public Driver(ICar car) {        this.car = car;    }    //司机的主要职责就是驾驶汽车    @Override    public void drive() {        this.car.run();    }}

2. Setter方法传递依赖对象

在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按照这个方式的注入，IDriver和Driver修改后代码：

代码清单14：IDriver.java

public interface IDriver {        //车辆型号    public void setCar(ICar car);        //是司机就应该会驾驶    public void drive();}

代码清单15：Driver.java

public class Driver implements IDriver {    private ICar car;    @Override    public void setCar(ICar car) {        this.car = car;    }    //司机主要职责就是驾驶    @Override    public void drive() {        this.car.run();    }}

3. 接口声明依赖对象，上面第二部分的例子就是采用了接口声明依赖的方式，该方法也叫做接口注入。

依赖倒置原则的本质就是通过（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，在项目中使用遵循以下的几个规则：