设计模式（Java版）
上QQ阅读APP看本书，新人免费读10天
设备和账号都新为新人
上一章目录下一章

2.3 依赖倒置原则

依赖倒置原则英文名称是：Dependence Inversion Principle，简称DIP。

2.3.1 依赖倒置原则的定义

依赖倒置原则的原始定义是：

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.

翻译过来，包括三层含义：

■ 高层模块不应该依赖低层模块，两者都依赖其抽象；

■ 抽象不依赖细节；

■ 细节应该依赖于抽象。

传统的过程性系统的设计办法倾向于高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。“倒置”原则将这个错误的依赖关系倒置了过来，如图2-5所示，由此命名为“依赖倒置原则”。

图2-5 依赖倒置原则

在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是具体的实现类，实现类实现了接口或继承了抽象类，其特点是可以直接被实例化。

依赖倒置原则在Java语言中的表现是：

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

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

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

依赖倒置原则更加精确的定义就是“面向接口编程”——OOD（Object-Oriented Design）的精髓之一。依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。依赖倒置原则是JavaBean、EJB和COM等组件设计模型背后的基本原则。

2.3.2 依赖倒置原则的应用

下述内容用于实现任务描述 2.D.3，演示依赖倒置原则的应用。在现实生活中，司机只要会开车，就可以开奔驰车，也可以开宝马车。因此司机不依赖于奔驰车或宝马车，而是通过如图2-6所示的接口，使他们之间的依赖关系倒置。

图2-6 依赖倒置原则的类图

司机接口只是一个抽象化的概念，是对司机这一类事物的抽象，只要是司机都有一个共同的行为，即“开车”，因此，在IDriver接口中使用drive()方法进行抽象。

司机接口IDriver的源代码如下所示。

【描述2.D.3】 IDriver.java

    //司机接口
    public interface IDriver {
        // 司机都会驾驶汽车
        public void drive(ICar car);
    }

上述代码中，在drive()方法中传入了ICar接口，这样实现了IDriver和ICar抽象之间的依赖关系。

司机类Driver实现IDriver接口，其源代码如下所示。

【描述2.D.3】 Driver.java

    //司机类
    public class Driver implements IDriver {
        // 司机的主要职责是驾驶
        public void drive(ICar car) {
            car.run();
        }
    }

汽车接口ICar的源代码如下所示。

【描述2.D.3】 ICar.java

    //汽车接口
    public interface ICar {
        // 汽车都能跑
        public void run();
    }

奔驰汽车类Benz实现ICar接口，其源代码如下所示。

【描述2.D.3】 Benz.java

    //奔驰车
    public class Benz implements ICar {
        public void run() {
            System.out.println("奔驰汽车在行驶......");
        }
    }

宝马汽车类BMW也实现ICar接口，其源代码如下所示。

【描述2.D.3】 BMW.java

    public class BMW implements ICar {
        public void run() {
            System.out.println("宝马汽车在行驶......");
        }
    }

在应用中，我们应贯彻“抽象不依赖细节”，即抽象（ICar接口）不依赖Benz和BMW两个实现类（细节），因此在高层次的模块代码中应用都是抽象的。下面编写一个测试类，其代码如下所示。

【描述2.D.3】 TestDIP.java

    public class TestDIP {
        public static void main(String[] args) {
            //实例化一个司机tom
            IDriver tom = new Driver();
            //实例化一辆宝马车
            ICar car = new BMW();
            //tom开车
            tom.drive(car);
        }
    }

上述代码中，当司机tom想开奔驰车时，只需要将“new BMW()”改为“new Benz()”即可，这样把“变更”引起的风险降低到最小。

注意 在Java中，只要定义变量就必须要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是创建时对象的类型。例如，tom表面类型是IDriver，实际类型是Driver。

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

■ 每个类尽量都具有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是抽象的，有了抽象才可能有依赖倒置；

■ 变量的表面类型尽量是接口或者是抽象类；

■ 任何类都不应该从具体类派生；

■ 尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。类之间依赖的是抽象，重写了非抽象方法，对依赖的稳定性会产生一定的影响；

■ 结合里氏替换原则使用。里氏替换原则指出父类出现的地方子类就可以出现，结合依赖倒置原则可以得出一个通俗的规则：接口负责定义抽象方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确地实现业务逻辑，同时在适当的时候对父类进行细化。

依赖倒置的原则在小型项目中很难体现出来，例如，使用SSH框架实现一个简单的小型项目，基本上不费太大的力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则具有非常多的优点，特别是规避一些非技术原因引起的问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则可以使接口或抽象类对实现类进行约束，从而减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就不能实现对扩展的开放，对修改关闭。在项目中，只要抓住“面向接口编程”就基本抓住了依赖倒置的原则。

上一章目录下一章