设计模式-依赖倒置-Dependency Inversion Principle

依赖倒置原则:

一般来说我们认为作为底层基础框架的逻辑是不应该依赖于上层逻辑的, 所以我们设计软件时也经常是:

需求 - 上层逻辑(直接实现需求) - 发现需要固化的逻辑 - 开发底层模块 - 然后上层调用底层逻辑.

但是这样做一开始是没问题的, 但是当上层剧烈变化时, 会不断的侵染底层逻辑, 底层逻辑虽然变动不大, 但是一旦变化, 成本极其高, 因为它要影响所有依赖于它的上层逻辑. 万一你改一个接口, 又不能兼容旧的方式. 除了引入适配器这种中间胶水层

别无他法, 但是这种胶水层如果不断变厚, 出现的更加频繁, 那么上层/胶水层/底层 的界限彻底的模糊. 维护是一个灾难. 所以胶水层的出现一般就意味着底层和上层逻辑出现了分歧. 底层设计需要适应变化.

一般来说应该尽力的避免胶水层的存在,至少要限制其发展, 不能变厚.(UNIX 编程艺术 Page 97)

在高层具体逻辑驱动的底层开发方式中. 底层的设计思路往往会被具体业务严重限制, 导致底层变成了特定上层的底层,失去通用性, 难以长期稳定. 大到整体方案的重新选择, 换个数据库, 换个OS平台? 小到一个接口的参数变化, 甚至命名的修改.

都会导致之前的工作无法有效继承延续下去, 导致工作内容无法复用. 大量工作付诸东流.

因此底层的开发千万不能由高层具体逻辑驱动, 那如何去做? 这就是依赖倒置原则的价值所在 !

既然底层不能依赖上层, 那么我们之前的设计思路就会出现问题, 在得到需求后首先设计上层就是问题的源泉. 那我们要从何处入手?

依赖倒置原则讲求的是: 上层不应该依赖于底层, 而是上层和底层都应该依赖于抽象. 或者说. 不要依赖任何具体类, 只依赖于抽象.

这里其实指明了一个道路. 都应该依赖于抽象, 也就是接到需求的第一步是设计抽象, 然而抽象什么? 这需要从依赖倒置最难理解的一部分说起: 倒置是什么?

依赖倒置, 我们可能会认为, 既然上层依赖底层是不对的, 那倒置了就是底层依赖上层? 这一点也是困惑的, 上层变化那么快, 底层不得疯掉?

所以依赖倒置这里和 "针对接口编程, 不针对具体实现编程" 的区别就在于: 这里是更加强调抽象, 强调依赖抽象去编程.

在频繁变化的需求下, 抽象是更加稳定的概念, 因此花更多的心思设计各层的抽象, 做到在一层之内做"具体依赖抽象",在各层之间做"抽象依赖抽象", 只有这样系统才会更加稳定和健壮.

所以倒置的依赖不是指向了具体的上层, 而是一个抽象的上层. 这里回到刚刚提出的问题, 我们从何处入手? 不是从具体的上层, 也不是底层, 而是抽象,并且是抽象的上层.

所以这里 倒置的是依赖, 依赖的是抽象, 抽象的是上层. 这三句话即是依赖倒置的步骤.

当然, 依赖倒置说的是不依赖具体,而依赖于抽象的上层, 这里是上层又可以做文章, 上层的抽象是"抽象的上层", 底层的抽象也是"抽象的上层". 所以很多地方画依赖倒置的图

有两个抽象类, 一边是对上层的抽象, 一边是对底层的抽象, 而抽象依赖抽象, 各自的"下层" 依赖各自的抽象. 形成一个桥型结构.

这两个抽象, 是我们需要首先深思熟虑的设计的.

这样是不是一切豁然开朗.

说到了这里, 或许还需要一个标准, 如何不违反依赖倒置原则:

1. 变量不持有任何具体类的引用 -> 持有抽象. 可以通过工厂+类族避免

2. 不要让类派生自任何具体类 -> 具体类是类族上一个具体的叶子节点, 依赖于叶子节点有两个可能: 他们是很像的兄弟. 单纯为了共享代码. 这两种情况, 不要偷懒, 考虑抽象一个父节点(接口,抽象类)挂上面

3. 不要覆盖基类中已经实现的方法 -> 如果你覆盖了, 那这个基类就失去了它的权威性, 这个被重写的函数大概蕴含着一个分支的类族. 如果一个类的很多有实现的方法被如此复写, 那这个类就是一个被子弹打成筛子的容器

那么, 结合上面三点, 你回顾下自己的代码, 是否感觉非常可怕(或者不可思议,不太可能)

设计模式的运用并不是一成不变,固守陈规.  在上述三个原则中, 是我们设计的标尺, 具体要视情况而定, 如果有更强烈的理由, 也可以打破这种限定. 所有的设计模式都是指导性的思想而并不是程序的评判标准.

有很多设计模式的思想,希望我们追求抽象, 希望我们消除if-else switch.但是这些思想都需要我们增加很多的类, 很多的继承关系. 造成了类的爆炸. 凡事必有一个度和界限. 设计亦是如此.

为了高可维护性, 高复用度去做的事情, 做的过分了就会出现边际效用递减的情况, 出现副作用, 弊大于利的情况.

这里设计做到什么程度的衡量标准用一个经典的话来说就是: 避免过渡设计, 避免提前设计. 
上面说的两个抽象类, 也是视复杂度设计为一个或者两个.

参考资料: HeadFirst 设计模式 Page: 139

喜欢这本书的原因就在于, 你的疑问, 他想得到还会立马给你解惑.

https://mp.weixin.qq.com/s/Kd1T40KZWvdThKC3IN6n-Q

优秀的架构师应该能在上述三角形张力区域中定位一个最适合目前研发团队状态的位置，例如在项目早期，CCP比REP更重要，随着项目的发展，这个最合适的位置也要不停调整。