|
概要
依赖倒置原则，从字面意思看的话，就是反映的是模块间依赖关系的问题。
目的
降低耦合，降低变更引发的风险，提高扩展性
实例与效果
先让我们从宏观上来看下，举个例子，我们经常会用到宏观的一种体系结构模式--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原则。 （编辑：安卓应用网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
