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

前端之家收集整理的这篇文章主要介绍了【设计模式攻略】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原则。

猜你在找的设计模式相关文章