此实现是组合还是聚合？

Question

我很困惑将组合和聚合与代码区分开来。例如，从以下代码中，代码的哪一部分表示它们的关系？

public class Account {
   private Owner owner;

   public Account(Owner owner) {
      this.owner = owner;
   }
}

public Owner {...}

Answer 1

关系是聚合还是合成是您在设计中做出的选择。

Owner对象的这种关系通常是（或者可能有）多个Account对象的聚合或组合，区别在于是否删除{ {1}}对象强制删除其Owner对象，即Account对象的生命周期是否依赖于拥有Account对象的生命周期。

Owner对象在代码中返回其拥有的Account对象的链接也很常见，但我认为大多数人不会将该链接视为一个组合或一个组合聚合。在这种情况下，Owner对象实际上是Owner个对象的组合，并且Account中的字段owner不允许为空，这很好。但并不一定如此。你的选择......

“真实世界”中发生的事情无关紧要。真正重要的是你如何选择建模。

Answer 2

• 聚合有三种 - 无，共享和组合。
• 组合聚合或组合严格按UML标准定义 - 当项目实例的生命受到容器或关联的生命限制时，它是组成。那么，可能是你的情况？但是根据标准，组合也假设一对多的关联多重性（一端为1，另一端为0 .. *），你在这里没有它！而且你正在从物品中寻找容器，这对于作品来说是不可能的！
• 未严格定义共享聚合。通常它是关于一个具有另一个实例的类。但这不是一个规则，而只是一种传统。你有这种情况。你可以将它命名为共享聚合。但你不需要。
  • （通常shared aggregation的名称只是aggregation，但这只是一个错误。为了缩短，您可以将其命名为shared。）
• 如果您没有合成并且您已确定没有共享聚合，则不使用聚合。所以，你也可以使用它。

所以，你所拥有的可以被命名为共享聚合或无聚合（后者更好）。但是你还有一种可能性。你在这里有classifier owned end。当一个类通过引用或直接具有另一个类的实例时。在UML标准中，它也被命名为atribute。并显示为虚线结束。

此外，您有权不显示导航箭头，点，多重性和聚合。 （您没有义务在图表上显示所有可能的信息 - 类图中最轻微的形式通常是起始变量）

因此，您可以使用以下变体：

在右侧，您可以使用空菱形，箭头，圆点或它们的任意组合。 variant变种是最好的，恕我直言。而且C也可以。

您可以调用您的关联共享聚合或无聚合。 您应该将您的关联称为分类器拥有/点缀的。

Answer 3

它是一个合成，因为您的Account对象必须与owner关联。

如果您允许创建帐户对象而没有任何与之关联的所有者，那么它就是一个聚合。

但是根据常见的业务逻辑，可能总是希望与所有者存在帐户。没有所有者的帐户没有任何意义。

组合是更严格的聚合版本。聚合只是简单地说“有一个”但你可以认为Composition更严格或必须创建一个对象（在你的情况下是Account对象）