均为原创，读架构整洁之道的笔记。
哪些类应该被组合在一起形成一个组件？很不幸的是，这个问题很重要，但我们通常会根据当下面临的情况临时拍脑门决定。
三个与构建组件相关的基本原则：
- REP：复用/发布，等同原则。
- CCP：共同闭包原则。
- CRP：共同复用原则。
REP 复用/发布等同原则
软件复用的最小粒度应等同于其发布的最小粒度。
Maven等包管理工具，日益重要的原因时正好在这十年间出现了大量可复用得组件和组件库。应该说我们现在至少已经实现了面向对象编程的一个原始初衷——软件复用。
如果想要复用某个软件组件的话，我们应该知道这个组建的发布版本号，如果没有版本号我们就无法保证这些组件能够互相兼容。软件开发者还必须知道这些组件的发布时间，和每次发布带来的变化。
只有这样，我们才能在收到新版本发布通知后，根据变更内容来决定要不要升级
从软件设计和架构的角度来看，REP原则就是指，组件中的类与模块必须是紧密相关的，它们应该有一个共同的主题或者大方向。
但是从另一个方面来说，这个原则就没这么简单了。因为根据该原则，组件内包含的类和模块，还应该是可以同时发布的。这意味着它们共享相同的版本号。这个偏向发布。
这个原则听起来比较薄弱，因为它并没能给出具体的指导，告诉我们应该如何将类与模块组合成组件。只是粗略的告诉我们它们应当紧密相关。
但是CCP和CRP会从相反的角度对这个薄弱性进行补偿。
CCP 共同闭包原则
我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
这其实是SRP原则在组件层面上的再度阐述。和SRP原则，一个类不应该同时存在多个变更的原因一样，CCP原则也认为一个组件不该同时存在多个变更原因。
因为可维护性应比复用性更重要。其次，如果变更都集中在一个组件中，那么我们就不需要再编译和部署其他组建了。
总而言之，CCP的主要作用就是让我们将易变动的，紧密相连的代码放在一个组件。这样能减少发布，验证，部署带来的压力。
由于100%闭包不可能，所以我们只能战略性选择闭包范围。我们只可能尽可能地将易变代码放在一起。
CCP原则就是SRP原则的组件版。
CRP 共同复用原则
不要强迫一个组件的用户依赖他们不需要的东西。
这个原则建议我们将经常共同复用的类和模块放在同一个组件中。通常情况下，类很少被单独使用，而是配合其他类一起使用。当我们的组件必须依赖其他组件时，最好是实际需要依赖该组件中的每个类。即不应该出现别人只需要依赖它的其中几个类，而不需要其他类的情况。
因此，它讨论的是不要将哪些类放到一个组件。
CRP原则上实际上ISP的一个普适版。ISP建议我们不要依赖带有不需要函数的类。CRP建议我们不要依赖带有不需要的类的组件。
一句话概括：不要依赖不需要用到的东西。
组件聚合张力图
以上三个原则是存在着竞争关系的。REP和CCP的原则是指导我们为了复用和维护性而组合。而CRP的原则是指导我们为了避免依赖而进行拆分。
我们应当在这个三角张力区定位一个最适合目前研发团队状态的位置，然后根据项目进行调整。一般来说早期，CCP原则会比REP更重要，因为速度比复用性更重要，后期依赖越来越多，则应当开始向REP倾斜。
本章小结
最初我们理解的组件是基于单一职责原则的，但是现在我们可以看到，这三个原则为我们描述了一个更为复杂的决策过程。并且这种组件聚合，是会根据项目进度动态去调整演化的。
