为何部分图示将Composition标记为Aggregation的子集？

• 从UML的官方定义来看，这是语义层级的划分：关联（Association）是类之间最宽泛的连接关系，聚合（Aggregation）是关联的子类，代表松散的整体-部分关系——部分可以脱离整体独立存在；而组合（Composition）是聚合的子类，属于强约束的整体-部分关系，部分的生命周期完全绑定在整体上（整体销毁时部分也会被销毁）。组合满足聚合的所有核心特征，只是多了额外的生命周期约束，所以被归为聚合的子集。

• 你感受到的耦合差异是代码实现层面的表现，而非UML语义的本质：你说组合是内部实例化、聚合类似依赖注入，这是具体编码时的实现方式，但UML的分类不看实现，只看语义逻辑。比如，就算用依赖注入的方式构建一个组合关系（比如把某个组件设为另一个组件的内部属性，且销毁容器时两者一起销毁），它依然是组合；反过来，要是你在内部实例化了一个对象，但允许它被外部引用、独立存活，那这反而属于聚合。

• 这种子集划分的逻辑和“正方形是长方形的子集”类似：正方形满足长方形的所有属性，只是多了“边长相等”的约束；组合也一样，满足聚合的整体-部分关系，只是多了“部分不能脱离整体存在”的强约束，所以被包含在聚合的范畴里。

内容的提问来源于stack exchange，提问作者janedoe