聚合与组合
Aggregation vs Composition
我想知道 Human 和 Driver License 之间的关系是聚合还是组合？我很清楚 Room 和 Building 关系是一种组合，而 Chair 和 Room 是一种聚合。但是 Driver License 可以在没有 Human 的情况下存在，但如果没有 Human，它的存在就毫无意义。我卡住了。
我认为要回答这个问题的疑问，我们应该准确定义以下术语：
- 上下文
- 上下文中存在实例
如果以上术语定义准确，那么使用组合或聚合就没有任何疑问。
我的想法，如果我要问这个问题，在我对术语的具体定义中：
- 上下文：现实世界
- 实例的存在并销毁它：实例的有用性与它的存在无关。销毁它意味着使它无效。我们应该在所有者消失后使其无效。 (但我们不会马上做)
因此，Human 和 Driver License 之间的关系不可能是 真实世界背景下的组合 。因为，通过摧毁Human（消失，失去生命，...），我们不会立即摧毁Driver License 。它存在。
例如（在某些国家/地区），没有任何在线和最新的失效机制可以使Driver License立即失效，因此可以没有 Driver 存在，直到我们使它无效。所以这段时间（从Driver消失到Driver License失效）它是存在的，Instance的用处与它的存在无关。再次注意：这是我对语境和存在的定义。
编辑（基于@Thomas Kilian 的评论）：
对于 Programming 上下文中的另一个示例及其技术（如 ORM），我们应该在删除 Driver 的实例后立即删除（无效）Driver License（我们可以在这种情况下做到这一点）。所以关系应该是一个组合。
最后：我想指出在建模中定义术语（上下文和现有术语以及其他相关术语）的重要性。如果我们不准确定义它们，就会出现许多解决问题的方法（基于他们头脑中隐藏的定义）。
希望有所帮助。
由于驾照不是 human/person 的一部分，而只是与 her/him 相关，因此它们之间既没有 Composition 也没有 Aggregation，只是一个普通的 Association。
Gholamali-Irani 的回答混淆了一个事实，即驾照必须与一个人相关联（即，resp. 关联端具有恰好一个多重性）与许多成分的（偶然）特征具有不可分割的部分，并错误地认为 Association 必须是 Composition。
在很多情况下，我们可能会怀疑关联是否是组合，将其建模为普通关联会更安全。
将关联（如 Human-has-DriverLicense）建模为组合的唯一充分理由是当组件类型（此处为驾驶执照）的实例为 "weak entities" 没有自己的身份。但是驾照确实有自己的 ID，因此没有必要，也没有任何好处，将它们建模为持有人的组成部分。
聚合 意味着 child 可以独立于 parent 存在的关系。示例：Class (parent) 和学生 (child)。删除 Class 学生仍然存在。
聚合示例:
请务必注意，聚合 link 并未以任何方式说明 Class A 拥有 Class B，也未说明存在 parent-child 关系（当parent 删除了两者之间的所有 child。事实上，恰恰相反！聚合link通常用来强调ClassA实例不是ClassB实例的独占容器，因为实际上同一个ClassB实例还有另一个container/s.
作文示例：
在 Class A 和 Class B 之间除了 part-of 关系之外，我们应该更具体地使用组合 link - 还有一个很强的关系两者之间的生命周期依赖性，意味着当 Class A 被删除时，Class B 也因此被删除
组合意味着 child 不能独立于 parent 存在的关系。示例：房屋 (parent) 和房间 (child)。房间不是独立于房子而存在的。
这里有一些额外的信息来阐述组合的概念
正如 Grady Booch 在 UML 用户指南中所述，Addison Wesley
However, there is a variation of simple aggregation - composition - that does add some important semantics. Composition is a form of aggregation, with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it. Such parts can also be explicitly removed before the death of the composite.
In addition, in a composite aggregation, the whole is responsible for the disposition of its parts, which means that the composite must manage the creation and destruction of its parts. For example, when you create a Frame in a windowing system, you must attach it to an enclosing Window. Similarly, when you destroy the Window, the Window object must in turn destroy its Frame parts.
（来源：UML 用户指南 - 作者：Grady Booch、James Rumbaugh、Ivar Jacobson、Addison Wesley）
总结 - (Read detailed Article)
总而言之，关联是一个非常通用的术语，用于表示何时在 class 上使用另一个 class 提供的功能。如果一个 parent class object 拥有另一个 child class object 并且 child class 我们说这是一个组合] object 没有 parent class object 就无法有意义地存在。如果可以，则称为聚合。
我想知道 Human 和 Driver License 之间的关系是聚合还是组合？我很清楚 Room 和 Building 关系是一种组合，而 Chair 和 Room 是一种聚合。但是 Driver License 可以在没有 Human 的情况下存在，但如果没有 Human，它的存在就毫无意义。我卡住了。
我认为要回答这个问题的疑问，我们应该准确定义以下术语：
- 上下文
- 上下文中存在实例
如果以上术语定义准确，那么使用组合或聚合就没有任何疑问。
我的想法，如果我要问这个问题，在我对术语的具体定义中：
- 上下文：现实世界
- 实例的存在并销毁它：实例的有用性与它的存在无关。销毁它意味着使它无效。我们应该在所有者消失后使其无效。 (但我们不会马上做)
因此，Human 和 Driver License 之间的关系不可能是 真实世界背景下的组合 。因为，通过摧毁Human（消失，失去生命，...），我们不会立即摧毁Driver License 。它存在。
例如（在某些国家/地区），没有任何在线和最新的失效机制可以使Driver License立即失效，因此可以没有 Driver 存在，直到我们使它无效。所以这段时间（从Driver消失到Driver License失效）它是存在的，Instance的用处与它的存在无关。再次注意：这是我对语境和存在的定义。
编辑（基于@Thomas Kilian 的评论）：
对于 Programming 上下文中的另一个示例及其技术（如 ORM），我们应该在删除 Driver 的实例后立即删除（无效）Driver License（我们可以在这种情况下做到这一点）。所以关系应该是一个组合。
最后：我想指出在建模中定义术语（上下文和现有术语以及其他相关术语）的重要性。如果我们不准确定义它们，就会出现许多解决问题的方法（基于他们头脑中隐藏的定义）。
希望有所帮助。
由于驾照不是 human/person 的一部分，而只是与 her/him 相关，因此它们之间既没有 Composition 也没有 Aggregation，只是一个普通的 Association。
Gholamali-Irani 的回答混淆了一个事实，即驾照必须与一个人相关联（即，resp. 关联端具有恰好一个多重性）与许多成分的（偶然）特征具有不可分割的部分，并错误地认为 Association 必须是 Composition。
在很多情况下，我们可能会怀疑关联是否是组合，将其建模为普通关联会更安全。
将关联（如 Human-has-DriverLicense）建模为组合的唯一充分理由是当组件类型（此处为驾驶执照）的实例为 "weak entities" 没有自己的身份。但是驾照确实有自己的 ID，因此没有必要，也没有任何好处，将它们建模为持有人的组成部分。
聚合 意味着 child 可以独立于 parent 存在的关系。示例：Class (parent) 和学生 (child)。删除 Class 学生仍然存在。
聚合示例:
请务必注意，聚合 link 并未以任何方式说明 Class A 拥有 Class B，也未说明存在 parent-child 关系（当parent 删除了两者之间的所有 child。事实上，恰恰相反！聚合link通常用来强调ClassA实例不是ClassB实例的独占容器，因为实际上同一个ClassB实例还有另一个container/s.
作文示例：
在 Class A 和 Class B 之间除了 part-of 关系之外，我们应该更具体地使用组合 link - 还有一个很强的关系两者之间的生命周期依赖性，意味着当 Class A 被删除时，Class B 也因此被删除
组合意味着 child 不能独立于 parent 存在的关系。示例：房屋 (parent) 和房间 (child)。房间不是独立于房子而存在的。
这里有一些额外的信息来阐述组合的概念
正如 Grady Booch 在 UML 用户指南中所述，Addison Wesley
However, there is a variation of simple aggregation - composition - that does add some important semantics. Composition is a form of aggregation, with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it. Such parts can also be explicitly removed before the death of the composite.
In addition, in a composite aggregation, the whole is responsible for the disposition of its parts, which means that the composite must manage the creation and destruction of its parts. For example, when you create a Frame in a windowing system, you must attach it to an enclosing Window. Similarly, when you destroy the Window, the Window object must in turn destroy its Frame parts.
（来源：UML 用户指南 - 作者：Grady Booch、James Rumbaugh、Ivar Jacobson、Addison Wesley）
总结 - (Read detailed Article)
总而言之，关联是一个非常通用的术语，用于表示何时在 class 上使用另一个 class 提供的功能。如果一个 parent class object 拥有另一个 child class object 并且 child class 我们说这是一个组合] object 没有 parent class object 就无法有意义地存在。如果可以，则称为聚合。