本文共 867 字,大约阅读时间需要 2 分钟。
依赖倒置原则,从字面意思看的话,就是反映的是模块间依赖关系的问题。 先让我们从宏观上来看下,举个例子,我们经常会用到宏观的一种体系结构模式--layer模式,通过层的概念分解和架构系统,比如常见得三层架构等。那么依赖关系应该是自上而下,也就是上层模块依赖于下层模块,而下层模块不依赖于上层,如下图所示。 这应该还是比较容易理解的,因为越底层的模块相对就越稳定,改动也相对越少,而越上层跟需求耦合度越高,改动也会越频繁,所以自上而下的依赖关系使上层发生变更时,不会影响到下层,降低变更带来的风险,保证系统的稳定。 上面是立足在整体架构层的基础上的结果,再换个角度,从细节上再分析一下,这里我们暂时只关注UI和Service间的关系,如下面这样的依赖关系会有什么样的问题? 第一,当需要追加提供一种新的Service时,我们不得不对UI层进行改动,增加了额外的工作。 第三,改动后,UI层和Logic层都必须重新再做Unit testing。 那么具体怎么优化依赖关系才能让模块或层间的耦合更低呢?想想前面讲的OCP原则吧,观点是类似的。 我们可以为Service追加一个抽象层,上层UI不依赖于Service的details,UI和Service同时依赖于这个Service的抽象层。如下图是我们的改进后的结果。 第一,Service进行扩展时,一般情况下不会影响到UI层,UI不需要改动。 第二,Service进行扩展时,UI层不需要再做Unit testing。 这就是所谓的依赖倒置原则,确实,如此的应用可能多少会增加一些额外的代码,并在局部也会带来复杂度的提升,但是它会让结构更灵活,更容易扩展。当然,有一点想说明的,我们也不该教条主义的去迎合每条原则,根据系统项目的需求,其实应该加上自己的判断。比如针对一些将来几乎不太可能被改动和扩展的类或模块,完全没有必要去迎合这条DIP原则。 转载地址:http://adeqj.baihongyu.com/