设计模式-依赖倒置

 

依赖倒置原则（Dependence Inversion Principle）

定义：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.

 

即：高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。

 

高层模块与低层模块：高层与低层的区分是相对的，不固定的，如果从“功能”角度出发，把“功能”看成是一个中国盒子，那么外面的盒子相对里面的盒子就是高层，里面的盒子相对外面的盒子就是低层。

 

抽象：抽象是什么？抽象就是抽象，因为抽象本身是不存在的，它恰恰与具象相反。在编程之外的世界，抽象通常作为一个动词来使用，抽象的意思是：屏蔽事物的不一致性，抽取出共性的过程。就像物理学解题中，经常把一些物体抽象成一个质点。

 

       这里的抽象就被用作一个动词，但在编程的世界中，因为语言差异，把abstract和abstraction都翻译成抽象，很明显，abstraction是名词的意思。再看之前依赖倒置原则的英文定义，用的是名词。那么在编程世界中，抽象的定义就应该是“屏蔽差异，抽取共性后的构造结果”。

 

       举个现实生活的例子，汽车就是轿车，越野车，跑车屏蔽各种车型差异后的抽象，而且被抽象的对象也可以是抽象本身，比如轿车也是大众轿车，福特轿车，丰田轿车的抽象。再想想之前举的“中国盒子”的例子，是不是有一种“太极生两仪，两仪生八卦，八卦生万象”无穷无尽的奇妙感觉？而在面向对象中，抽象可以是类，属性，也可以是行为（接口本身可以视为一种类）。

 

细节：理解了抽象就很好理解细节了，细节就是抽象的实现。

 

       理解了定义的各部分后，我们可以总结得出，所谓的“依赖倒置原则”，可以理解成为：高层模块使用低层模块的抽象，低层模块实现抽象。抽象只考虑共性，由于所谓共性之中本身存在细节上的差异，所以抽象的时候，不应该考虑这些差异，但是低层模块实现抽象的时候，必须遵循产出是抽象出来的共性这一点。

 

      英文定义直译过来有时候很难理解，所以需要转换成自己的理解，才能消化。下面我们来举个例子：比如，我们要实现人的吃饭功能（原谅我现在肚子 有点饿），这是未使用依赖倒置的设计，

 

  图中，我们可以看到，人有一个行为叫“吃饭”，而吃饭直接依赖米和面这两个对象。像这样的设计，如果再加一种食物，比如土豆，不仅要增加土豆的类，还要修改人的“吃饭”行为。这将非常不利于系统的扩展。

 

  而如果我们采用依赖倒置的设计，那么设计会是这样的：

 

 

  人“吃饭”的行为不再直接依赖米饭和面条这样具体的低层模块，而是依赖于米饭、面条这些具象的抽象结果——食物。如果这时候，来了土豆，玉米，只需要实现我们的抽象“食物”，而人的吃饭行为因为依赖于食物这个抽象，所以不再需要改动。

 

这就是采用依赖倒置设计的好处。

 

依赖倒置的代码太多了，吾懒劲已上，诸君可自搜。