《设计模式之禅（第三版）》摘录篇-------依赖倒置原则

矫情吗；* 2022-04-02 06:28 103阅读 0赞

**依赖倒置原则（**（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，面向对象设  
计）的精髓之一。

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

**依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D……生生不息，依赖不  
止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！**

象的依赖关系有三种方式来传递，如下所示。

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

代码清单3-11 构造函数传递依赖对象  
public interface IDriver \{  
//是司机就应该会驾驶汽车  
public void drive();  
\}  
public class Driver implements IDriver\{  
private ICar car;  
//构造函数注入  
public Driver(ICar \_car)\{  
this.car = \_car;  
\}  
//司机的主要职责就是驾驶汽车  
public void drive()\{  
this.car.run();  
\}  
\}

**2.Setter方法传递依赖对象**

在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按  
照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-12所示。  
代码清单3-12 Setter依赖注入  
public interface IDriver \{  
//车辆型号  
public void setCar(ICar car);  
 //是司机就应该会驾驶汽车  
public void drive();  
\}  
public class Driver implements IDriver\{  
private ICar car;  
public void setCar(ICar car)\{  
this.car = car;  
\}  
//司机的主要职责就是驾驶汽车  
public void drive()\{  
this.car.run();  
\}  
\}

**3.接口声明依赖对象**

**依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，  
不互相影响，实现模块间的松耦合，**我们怎么在项目中使用这个规则呢？只要遵循以下的几  
个规则就可以：  
**● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备**  
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。  
**● 变量的表面类型尽量是接口或者是抽象类**  
很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具  
类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须  
使用实现类，这个是JDK提供的一个规范。  
**● 任何类都不应该从具体类派生  
如**果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝  
对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都  
是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么？维护工  
作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个  
很大的Bug，何必去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或者无法  
获得父类代码的情况下。）  
**● 尽量不要覆写基类的方法**  
如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是  
抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。  
**● 结合里氏替换原则使用**  
在第2章中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章的讲  
解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他  
对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适  
当的时候对父类进行细化。