这是我参与11月更文挑战的第14天，活动详情查看：2021最后一次更文挑战
前言
上一篇讲述了架构设计时组件聚合三大原则，复用/发布等效原则、共同封闭原则和共同重用原则，主要阐述组件组合，类或模块的组合，组合后应该“同生共死”，而不是”牵一发而动全身“。完美将类和模块组成组件后，接下来就是解决组件之间的关系，需要在开发效率和逻辑设计之前权衡。
组件耦合
解决组件之间的关系,可以根据组件耦合三大原则考虑：
- 无环依赖原则
- 稳定依赖原则
- 抽象依赖原则
无环依赖原则
组件依赖图遵守无环的设计
每周构建
在中等规模的项目中，每个开发者都是用独立的分支开发，然后在上线的时间再集成，构建系统进行部署。但是如果一个版本期限过长的时候，将会导致集成困难度增大，这种情况将会导致灾难。
所以，为了维持效率，避免项目规模增长过长中，集成的时间变长，建议每周构建，可有效预防集成时出现的冲突等相关问题。
消除依赖循环
将开发环境分割多个可发布的组件，且每个组件都有其版本号。划分多个组件是数个工作单元，每个工作单元有各自开发者或者各自团队负责。这样独立开发，独立发布部署，其他团队都按需根据版本号使用想要的组件版本。整个过程必须管理好组件依赖结构，不能有循环依赖的组件存在。
组件依赖图中有循环依赖的影响
现实需求中肯定会出现循环依赖，遇到了该怎么解决？
- 使用依赖倒置原则DIP，解除循环依赖
- 创建新组件，把问题的类的都移到新的组件
稳定依赖原则
依赖直接的稳定的东西
设计不可能是静态的，设计时 保留易变性时必要的。
-
稳定性：稳定性和改变的频率无直接关系，可以理解为“不易动”。
-
稳定指标
- 扇入传入依赖，这个指标是外部组件的类依赖该组件类的数量
- 扇出传出依赖，这个指标是该组件内部的类依赖外部组件的类的数量
- 不稳定度I = （扇出）/（扇出+扇入），这个值的区间是[0,1], I = 0 表示组件最为稳定，1则是最不稳定。
-
并非左右组件都应该是稳定的
-
抽象组件
稳定抽象原则
组件具备稳定性时，也应该具备抽象性
稳定抽象原则是决定稳定性和抽象性的联系
- 稳定组件应该具备抽象性，以便扩展。
- 不稳定组件应该被具体实现，因为不稳定允许具体实现的代码能容易变化。
抽象度的衡量
定义用A值衡量一个组件的抽象度。这个值是是一个组件里接口和抽象类总数和这个组件的类总数的比值。
- Nc: 组件里的类的总数
- Na: 组件里的接口和抽象类的总数
- A: 抽象度A=Na/Nc
抽象度A值的区间为[0,1]，A=0意味着组件里没有抽象性的类，A=1意味着组件仅仅只包含抽象性的类。
依赖管理度量值描述一个设计满足于一个好的依赖和抽象的模式的度量，只是一个参考的值，具体场景还需要根据具体的情况分析。
\
