聚合vs组成

我认为,要回答这个问题中的疑问,我们应该准确定义以下术语:

1. 上下文
2. 在上下文中存在实例

如果上述术语定义准确,那么使用组合或聚合毫无疑问。

我的想法 ,如果我想问这个问题,在我对术语的具体定义中:

1. 上下文 : 真实世界
2. 实例的存在性 摧毁它:实例的有用性与它的存在无关。摧毁它意味着使它无效。我们应该在主人消失后将其作废。( 但我们不会立即这样做 )

那么 Human 和a Driver License 不可能是 中的一篇作文 真实世界背景 . 因为,通过破坏 人类 驾驶执照 立即 . 它存在。

例如(在某些国家),没有任何在线和最新的失效机制来失效 驾驶执照 ,因此它可以在没有 Driver 直到我们宣布它无效。所以 在这段时间内 (从消失 驾驶员 使 驾驶执照 )它是存在的,实例的有用性与它的存在无关。请再次注意:这是我对语境和存在的定义。

编辑 (根据@Thomas Kilian的评论):
另一个例子是 编程 对于技术(如ORM),我们应该删除(使其无效) 驾驶执照 删除的实例后立即 驾驶员 (我们可以在这种情况下做到这一点)。因此,这种关系应该是一种组合。

最后 :我想指出 的重要性 建模中术语(上下文、现有术语和其他相关术语)的定义。如果我们不准确地定义它们,问题就会出现许多解决方案(基于他们心中隐藏的定义)。

希望对您有所帮助。

由于驾照不是人/人的一部分,而是与人/人相关的,因此两者之间既没有组合,也没有聚合,只有简单的关联。

Gholamali Irani的回答混淆了驾驶执照必须与一个人相关联的事实(即,责任关联端有一个确切的多重数)和许多组成部分的(或有)特征有不可分割的部分,并错误地得出结论,即关联必须是一个组成部分。

在许多情况下,如果我们想知道一个关联是否是一个组合,那么更安全的做法是将其建模为一个简单的关联。

建模关联的唯一好理由(如 Human -有- DriverLicense )当组件类型的实例(这里是驱动程序许可证)是没有自己身份的“弱实体”时,就构成了一种组合。但驾照确实有自己的ID,因此没有必要也没有好处将其建模为持有者的组成部分。

聚合 意味着子级可以独立于父级存在的关系。例如:班级(家长)和学生(孩子)。删除该类,学生仍然存在。

聚合示例 :

重要的是要注意,聚合链接并没有以任何方式声明类A拥有类B,也没有声明二者之间存在父子关系(当父级删除了其所有子级时,其结果将被删除)。事实上,恰恰相反!聚合链接通常用于强调类A实例不是类B实例的独占容器,因为实际上同一个类B实例有另一个容器。

组成示例:

我们应该更具体一些,在除了类A和类B之间的部分关系之外,二者之间还有很强的生命周期依赖关系的情况下使用合成链接,这意味着当删除类A时,也会删除类B

这里有一些额外的信息来阐述构图的概念

作为什么 布奇 如UML用户指南所述,Addison Wesley

然而,有一种简单聚合的变体- 作文 -这确实增加了一些重要的语义。组合是一种聚合形式,具有强大的所有权和作为整体一部分的重合寿命。 具有非固定多重性的零件可以在复合材料本身之后创建,但一旦创建,它们就会随之生存和消亡。 这些部件也可以在复合材料失效之前明确移除。

此外,在复合聚合中,整体负责其部分的处置,这意味着复合必须管理其部分的创建和销毁。例如,在窗口系统中创建框架时,必须将其附着到封闭窗口。 类似地,销毁窗口时,窗口对象必须依次销毁其框架部分。

(来源:UML用户指南-作者:Grady Booch、James Rumbaugh、Ivar Jacobson、Addison Wesley)

总结一下 - ( Read detailed Article )

总之,关联是一个非常通用的术语,用于表示在类上使用另一个类提供的功能。如果一个父类对象拥有另一个子类对象,并且没有父类对象,该子类对象就不能有意义地存在,那么我们说它是一个组合。如果可以,则称为聚合。