消除循环依赖-即依赖关系图不应该出现环
典型的例子：A->B->C->A，四个组件，最终形成了一个环，环内的组件互相依赖。最终导致的一个问题是，每个组件的修改，都可能影响到另外三个组件，书中称为“一觉醒来综合征”，即我们不知道什么时候就会被其它组件影响，从而导致我们要付出很多的时间去做适配。
一个场景，如果A组件做了修改，本来我们可以只用A/B组件就可以验证功能是否OK，然而有循环依赖后，我们必须依赖换上的所有组件进行验证；
另一个场景，设计过程中，我们要分析我们的修改会影响哪些组件，结果发现换上的任何组件都会受影响，我们不得不去跟这些所有的组件都去讨论方案、排计划，拉通、对齐。。。
总结起来，任何一个修改，都可能影响到环上的所有组件。
两种方法消除循环依赖
常见的，DIP，依赖翻转原则，例如A->B->C->D->A，通过依赖翻转，可以修改为A->B->C->D,D->C（D定义一个抽象类，A继承，实现代码上的依赖翻转），这样当C做了修改，只需要考虑依赖它的B和A，D不会受到影响。
另一种方法，提取公共组件，例如A->B->C->D->A，提取出公共组件E，依赖变为A->B->C->D->E,A->E。但是这种在实际操作中就会打破各团队的既有利益分配，哪个团队维护新的组件？又要扯皮一下？
这也可以看出，架构设计，或者组件依赖关系，不是从一开始就能完美确定的。需要在系统构建过程中不断的变化，从最开的共同闭包原则构建组件，到共同复用原则拆分组件间，随着组件的增多又不可避免的可能产生循环依赖，再通过依赖翻转原则消除循环依赖，组件设计是在不断的扩张和波动的。
稳定依赖原则
组件间肯定是有依赖的，到底哪些组件需要被依赖，哪些组件需要依赖别人呢？有一个基本的原则，就是易变的组件依赖稳定的组件。
那什么是稳定的组件，书中提到了一个判断方法：入依赖和出依赖。入依赖即有多少组件依赖本组件，出依赖即本组件依赖多少其它组件。入依赖越多，说明越难修改（修改的影响性越大），即越稳定。稳定的组件并不是不常修改，而是修改的工作量大。
稳定抽象原则
依赖抽象，而不是依赖具体实现。
稳定的组件，往往被多个组件所依赖，导致很难被修改。但修改是不可避免的，因此考虑到灵活性，那就需要考虑这样一个原则，约稳定的组件，越要提供抽象类，其它组件依赖抽象类，而不是具体实现。
***********************************************************************
【如果文字看累了，可b站搜索“沙皮狗2021”，用听的方式领略知识的魅力】
传送门 ：https://space.bilibili.com/407643589
【微信公众号】：沙皮狗2021