【设计模式攻略】OO设计原则之DIP-依赖倒置原则

概要

依赖倒置原则，从字面意思看的话，就是反映的是模块间依赖关系的问题。

目的

降低耦合，降低变更引发的风险，提高扩展性

实例与效果

先让我们从宏观上来看下，举个例子，我们经常会用到宏观的一种体系结构模式--layer模式，通过层的概念分解和架构系统，比如常见得三层架构等。那么依赖关系应该是自上而下，也就是上层模块依赖于下层模块，而下层模块不依赖于上层，如下图所示。

这应该还是比较容易理解的，因为越底层的模块相对就越稳定，改动也相对越少，而越上层跟需求耦合度越高，改动也会越频繁，所以自上而下的依赖关系使上层发生变更时，不会影响到下层，降低变更带来的风险，保证系统的稳定。

上面是立足在整体架构层的基础上的结果，再换个角度，从细节上再分析一下，这里我们暂时只关注UI和Service间的关系，如下面这样的依赖关系会有什么样的问题？

第一，当需要追加提供一种新的Service时，我们不得不对UI层进行改动，增加了额外的工作。

第二，这种改动可能会影响到UI，带来风险。

第三，改动后，UI层和Logic层都必须重新再做Unit testing。

那么具体怎么优化依赖关系才能让模块或层间的耦合更低呢？想想前面讲的OCP原则吧，观点是类似的。

我们可以为Service追加一个抽象层，上层UI不依赖于Service的details，UI和Service同时依赖于这个Service的抽象层。如下图是我们的改进后的结果。

这样改进后会有什么好处呢？

第一，Service进行扩展时，一般情况下不会影响到UI层，UI不需要改动。

第二，Service进行扩展时，UI层不需要再做Unit testing。

应用

这就是所谓的依赖倒置原则，确实，如此的应用可能多少会增加一些额外的代码，并在局部也会带来复杂度的提升，但是它会让结构更灵活，更容易扩展。当然，有一点想说明的，我们也不该教条主义的去迎合每条原则，根据系统项目的需求，其实应该加上自己的判断。比如针对一些将来几乎不太可能被改动和扩展的类或模块，完全没有必要去迎合这条DIP原则。