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

发布时间：2020-12-14 05:15:16 所属栏目：百科来源：网络整理

导读：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

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语言中的表现就是：

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

再次理解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 
    
   
 public?interface?IDriver{??
 ????//是司机就应该会驾驶汽车??
 ????void?drive();??
 }??
 ??
 class?Driver?implements?IDriver{??
private?ICar?car;??
//构造函数注入??
public?Driver(ICar?_car){??
 ????????this.car?=?_car;??
 ????}?????
//司机的主要职责就是驾驶汽车??
void?drive(){??
this.car.run();??
 ????}??
 }??

B.Setter方法传递依赖对象

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

copy 
    
   

?IDriver?{??

//车辆型号??
void?setCar(ICar?car);??
????void?setCar(ICar?car){??
????????this.car?=?car;??
????}??
????//司机的主要职责就是驾驶汽车??
void?drive(){??
this.car.run();??
}??

C.接口声明依赖对象

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

copy 
    
   

?drive(ICar?car);??

void?drive(ICar?car){??
????????car.run();??
}??

8.范例：

8.1 面对实现编程

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

司机驾驶奔驰车类图

copy

//司机源代码??

class?Driver{??
//是司机就应该会驾驶汽车??
void?drive(Benz?benz){//1??
????????benz.run();??
}??
//奔驰源代码??
class?Benz{??
//汽车肯定会跑??
void?run(){??
????????System.out.println("奔驰汽车开始运行。。。");??
//场景类源代码??
class?Client{??
static?void?main(String[]?args){??
????????Driver?zhangsan?=?new?Driver();??
????????Benz?benz?=?new?Benz();//2??
????????//张三开奔驰车??
????????zhangsan.drive(benz);??
但假若现在给出宝马类，发生变更呢？
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
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. } ?
  （编辑：李大同）
  
  【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!