设计模式六大原则3：依赖倒置原则

设计模式 2020-09-05

1. 定义

  依赖倒置原则 (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.

即  1、高层模块不应该依赖低层模块，两者都应该依赖于抽象（抽象类或接口）  

      2、抽象（抽象类或接口）不应该依赖于细节（具体实现类）  

      3、细节（具体实现类）应该依赖抽象


2.理解：

低层模块：不可分割的原子逻辑；

高层模块：低层模块的再组合；

抽象：   接口或抽象类（特点：不能直接被实例化）；

细节：   与接口或抽象类对应的实现类（特点：可以直拉被new实例化）；


据此，DIP在Java语言中的表现就是：

  1. 模块间的依赖通过抽象类或接口发生，实现类之间的依赖关系也是通过抽象类或接口产生（实现类之间不应发生直接的依赖关系）；
  2. 接口或抽象不依赖于实现类，但实现类依赖接口或抽象类；

再次理解DIP：

依赖倒置原则 要求"高层模块不应该依赖于低层模块，二者都应该依赖于抽象。"这一原则在分层架构模式中，得到了淋漓尽致地运用。例如，业务逻辑层（高层模块）的对象就不应该直接依赖于数据访问层（低层模块）的具体实现对象，而应该通过数据访问层的抽象接口进行访问，如下图所示。如果高层模块直接依赖于低层模块，一旦低层模块发生变化，就会影响到高层模块。通过引入抽象，对于高层模块而言，低层模块的实现是可替换的。这实际上也是"开放封闭原则"的体现。这一原则同时还体现了软件设计对"间接"的追求。下图中的数据访问抽象层就是在设计中引入的一层间接性。

依赖倒置原则还要求"抽象不应该依赖于细节，细节应该依赖于抽象"。这与之前的要求一脉相承。关键仍然是"抽象"，抽象属于高层，细节属于低层，低层依赖于高层，而不是高层依赖于低层，这正是依赖倒置的真谛。依赖倒置原则与"面向接口编程"的思想不谋而合。GOF在《设计模式》一书中旗帜鲜明地提出了面向对象设计的首要原则，那就是"针对接口编程，而不是针对实现编程"。因为客户程序关心的仅仅是对象提供什么功能，而不是功能如何实现，甚至不关心对象的具体类型。这就好像电源插头只关心插座是两相还是三相，而无需知道插头如何与插座内的电线相连。

什么是依赖“正置”、“反置”？
依赖正置：类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程。这也是正常人的思维方式，比如要开奔驰就开奔驰（而没考虑宝马）。
依赖倒置：编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”便由此而生。

3.问题由来：

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。[解决方案]将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

4.使用DIP的好处：

  • 可以通过抽象使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合（也是本质）；
  • 可以规避一些非技术因素引起的问题（如项目大时，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增情况。同时，发生人员变动，只要文档完善，也可让维护人员轻松地扩展和维护）；
  • 可以促进并行开发（如，两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD开发模式更是DIP的最高级应用（特别适合项目人员整体水平较低时使用））。

5.难点：

  • DIP是6大原则中最难以实现的原则，它是实现开闭原则的重要途径，DIP没有实现，就别想实现对扩展开放，对修改关闭。在项目中只要记住“面向接口编程”就基本上抓住了DIP的核心。
  • 使用此原则时要审时度势，每个原则的优点都是有限度的，所以别为一个原则而放弃了终极目标：投产上线和盈利。

6.实践建议：

  • 每个类尽量都有接口或抽象类，或者二者都有；（有了抽象才可能DIP）
  • 变量的声明类型尽量是接口或抽象类；（工具类一般不需要）

  • 任何类都不应该从具体类派生；（如果项目处于开发状态，就不应该有这种情况，当然，设计缺陷在所难免，因此不要超过两层的继承。但对于项目维护者来说，可以不用考虑这个规则，因为维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的bug，何必去继承最高的基类呢？（当然不应该轻易继承，之所以要这样，是因为可能不甚了解父类或者无法获得父类的代码））

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

  • 结合里氏替换原则使用（上一个章节中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章节的讲解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。）

    •          依赖倒置原则是六个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒转原则的核心。

    7.依赖的三种写法：

    依赖是可以传递的，只要做到抽象依赖，即使是多层的依赖传递也无所畏惧。

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

      比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

    [java]  view plain copy
    1. public interface IDriver{  
    2.     //是司机就应该会驾驶汽车  
    3.     void drive();  
    4. }  
    5.   
    6. class Driver implements IDriver{  
    7. private ICar car;  
    8. //构造函数注入  
    9. public Driver(ICar _car){  
    10.         this.car = _car;  
    11.     }     
    12. //司机的主要职责就是驾驶汽车  
    13. void drive(){  
    14. this.car.run();  
    15.     }  
    16. }  

    B.Setter方法传递依赖对象

    即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象

    copy
      interface IDriver {  
    1. //车辆型号  
    2. void setCar(ICar car);  
    3.     void setCar(ICar car){  
    4.         this.car = car;  
    5.     }  
    6.     //司机的主要职责就是驾驶汽车  
    7. void drive(){  
    8. this.car.run();  
    9. }  

    C.接口声明依赖对象

      在接口的方法中声明依赖对象，该方法也叫做接口注入。

    copy
      void drive(ICar car);  
    1. void drive(ICar car){  
    2.         car.run();  
    3. }  

    8.范例：

    8.1 面对实现编程

     （当然，这里为了展现出问题，当然最小需求时，可以这样。。。）


    司机驾驶奔驰车类图


    copy

      //司机源代码  
    1. class Driver{  
    2. //是司机就应该会驾驶汽车  
    3. void drive(Benz benz){//1  
    4.         benz.run();  
    5. }  
    6. //奔驰源代码  
    7. class Benz{  
    8. //汽车肯定会跑  
    9. void run(){  
    10.         System.out.println("奔驰汽车开始运行。。。");  
    11. //场景类源代码  
    12. class Client{  
    13. static void main(String[] args){  
    14.         Driver zhangsan = new Driver();  
    15.         Benz benz = new Benz();//2  
    16.         //张三开奔驰车  
    17.         zhangsan.drive(benz);  
    18. 但假若现在给出宝马类，发生变更呢？

      copy

        //宝马车源代码  
      1. class BMW{  
      2. //汽车肯定会跑  
      3. void run(){  
      4.         System.out.println("宝马汽车开始运行。。。");  
      5. }  
      看看，宝马有了，却不能让张三开起来，这也太不合理了，我们的设计出了问题：司机类和奔驰类之间是 紧耦合 的关系，其导致的结果就是系统的可维护性大降低，可读性降低。//若需要改为开宝马，必须得更改上述标注的 第1（低层模块，太不应该）、2（高层模块，业务变化，应该略做更改，正常） 处才可以。

      8.2 现根据DIP原则，重新编写如下：

      引入DIP后的类图

      下面建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入ICar接口，至于到底是哪个类型号的Car，需要在高层模块中声明或修正。

      copy

          
      1. interface ICar{  
      2. //是汽车就应该能跑  
      3. void run();  
      4. //奔驰源代码  
      5. class Benz implements ICar{  
      6.         System.out.println("奔驰汽车开始运行。。。");  
      7. class BMW //可更改这里  
      8.         zhangsan.drive(benz); }     
      若为宝马了，只需在高层模块进行变换（上述浅兰标注），代码如下：

      copy

                    BWM bwm = new BWM();  
      1. //张三开宝马  
      2.         zhangsan.drive(bwm);  
      3. 这样，在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要任何修改，业务就可以运行，
        把变更引起的风险降低到最小。
        8.3  再来思考依赖倒置对并行开发的影响。

        两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD(Test-Driven Development,测试驱动开发)开发模式就是DIP的最高级应用。

        回顾上述例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口，就可以独立地开发了，甲开发进度比较快， 完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？可以，我们引入一个JMock工具，其最基本的功能就是根据抽象虚拟一个对象进行测试，测试类如下所示：
        copy
          //测试类  
        1. class DriverTest extends TestCase{  
        2.     Mockery context = new JUnit4Mockey();  
        3.     @Test  
        4. void testDriver(){  
        5. //根据接口虚拟一个对象  
        6. final ICar car = context.mock(ICar.class);  
        7.         IDriver driver =          //内部类  
        8.         context.checking(new Expectations()){  
        9.             oneOf(car).run();  
        10.         });  
        11.         driver.drive(car);  
        12. }  

        相关文章

        什么是设计模式？Design pattern--和生活结合更好理解
        什么是设计模式一套被反复使用、多数人知晓的、经过分类编目...
        面向对象设计原则一——单一职责原则
        单一职责原则定义（Single Responsibility Principle，SRP）...
        十分钟理解Java中的动态代理----强烈推荐
        动态代理和CGLib代理分不清吗，看看这篇文章，写的非常好，强...
        适配器模式-让不兼容的接口得以适配
        适配器模式将一个类的接口转换成客户期望的另一个接口，使得...
        策略模式-定义一个算法族
        策略模式定义了一系列算法族，并封装在类中，它们之间可以互...
        设计模式之高质量代码
        设计模式讲的是如何编写可扩展、可维护、可读的高质量代码，...