哪些类应该被组合成一个组件

---

前言

我们日常的开发中，经常会写各种各样的类，但是哪些类应该组成一个组件，这个问题我们时常会有疑问。按照正常的逻辑，如何聚合应该按照最佳的软件工程经验来做。但是实际的做法，大部分都是拍脑门决定的，都是想当然。
在长时间的软件工程实践中，人们总结出了三大基本原则。

---

一、复用/发布原则

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

这句话是说软件组件中的类和模块必须是彼此紧密相关的，一个组件不能由一组毫无关联的类和模块组成，他们应该有一个共同的主题或者大方向。比如说做饭，需要有买菜，做菜，端菜这几个大的过程，我们可以吧买菜相关的类放在一起，组成一个组件。
一个组件中的类与模块应该是可以同时发布的，意思是买菜方法改进了，变成了买菜2.0，升级买菜过程的时候不应该受到做菜方法的影响。能独立的进行组件升级。

二、共同闭包原则

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

一个组件不应该同时存在多个变更原因。

这个原则告诉我们，对于大部分软件来说，可维护性的重要性要远远高于可复用性。如果某程序中的代码必须进行某些变更，那么这些变更最好都体现在一个组件内，而不是多个组件中。如果是这些变更在一个组件中，我们就只需要重新部署该组件，而其他组件不需要被重新验证、重新部署。这样就有效降低了因为软件发布，验证，部署带来的工作压力。
在这个原则基础上，还可以进一步延伸，可以把某一类变更都聚合在一起，意思是比之前的相同目的修改更高一级聚合，最大限度减少因该类变更导致的修改。

---

三、共同复用原则

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

共同复用原则是另外一个帮助我们决策类和模块归属于哪一个组件的原则。该原则建议我们将经常共同复用的类和模块放在同一个组件内。
通常情况下，类很少会被单独复用。更常见的情况是多个类同时作为某个可复用的抽象定义被共同复用。共同复用原则指导我们将这些类放在同一个组件中，而在这样的组件中，我们应该遇见到会存在着许多相互依赖的类。
共同复用的原则，不仅是告诉我们应该将哪些类放在一起，更重要的是告诉我们应该将哪些类分开。因为当一个组件引用了另一个组件时，就等于增加了一条依赖关系。虽然这个引用关系仅涉及被引用组件中的一个雷，但他所带来的依赖关系丝毫没有减弱。也就是说引用组件已然依赖于被引用的组件。
举个例子，我们引用了一个jar包，这个jar包引用了一个很大的另外一个jar包，但是其实只用了其中一个很小的util类，这种情况，就会导致，就会给我们的项目带来很大的维护风险，依赖的越多，越有可能会冲突。发布的包就会越大，相应的运行和存储空间就成几何倍数增长。

组件聚合张立图