组件构建原则

1. 前言

如果说SOLID原则是用于指导我们如何将砖块砌成墙与房间的，那么组件构建原则就是用来指导我们如何将这些房间组合成房子的。我的理解是，好的组件应该保持其能够独立开发、测试和部署。

2. 组件聚合

组件聚合主要讨论的是将哪些类放在同一个组件中，基本原则有：

REP：复用/发布等同原则

CCP：共同闭包原则

CRP：共同复用原则

2.1 REP复用/发布等同原则

软件复用的最小粒度应等同于其发布的最小粒度。

REP原则就是指组件中的类与模块必须是彼此紧密相关的，也就是说，一个组件不能由一组毫无关联的类和模块组成，他们之间应该有一个共同的主题或者大方向。2.2和2.3则是对2.1的补充，详细介绍了通过何种方式实现复用/发布等同原则。

2.2 CCP共同闭包原则

我们应该将那些会同时修改，并且为相同目的而修改的类放在同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放在不同的组件中。

正如SOLID原则中的单一职责中提到的 “一个类不应该同时存在多个变更原因”一样，共同闭包原则也认为一个组件不应该同时存在多个变更原因，而这样子也极大的提高了组件的可维护性，如果某程序需要进行某些变更，那么这些变更最好都体现在同一个组件中，而不是分布于很多组件中，只需要重新验证和部署该组件就可以了。

2.3 CRP共同复用原则

不要强迫一个组件的用户依赖他们不需要的东西。

该原则建议我们将经常共同复用的类和模块放在同一个组件中，更重要的是，希望不要出现别人只需要依赖组件中的某几个类而不需要其他类的情况，否则，后续会因为不需要的其他类变更，导致不必要的重新部署。因此CRP原则指导我们：不是紧密相连的类不应该被放在同一个组件里。

与接口隔离原则类似，共同复用原则是其普适版。

2.4 组件聚合原则的张力图

上述三个原则之间彼此存在着竞争关系，REP和CCP是粘合性原则，他们会让组件变得更大，而CRP原则是排除性原则，他会让组件变得更小。架构师的任务就是在这三个原则中进行取舍，下图2-4是三大原则的张力图，边线所描述的是忽略对向原则导致的后果。

图2-4 组件聚合原则张力图

如果只关注REP和CRP，会导致即使是简单的变更也会同时影响到许多组件。

如果过于关注REP和CCP，会导致很多不必要的发布。

架构师需要做的是在上述三角张力区域中定位一个最适合目前研发团队状态的位置，同时也会根据时间不停调整。一般来说，软件项目的重心会从该三角区域的右侧开始，先期主要牺牲的是复用性，然后，随着项目的 逐渐成熟，其他项目会逐渐开始对其产生依赖，项目会逐渐向该三角区域的左侧滑动。换句话说，一个项目在组件结构设计上的重心是根据该项目的开发时间和成熟度不断变动的。

3. 组件耦合

组件耦合主要是讨论组件之间的关系。

3.1 无依赖环原则

组件依赖关系图中不应该出现环。

3.2 自上而下的设计

3.3 稳定抽象原则