Java 这个实现是组合还是聚合？

我不知道如何将组合和聚合与代码区分开来。例如，从以下代码中，代码的哪一部分表示它们之间的关系

public class Account {
   private Owner owner;

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

public Owner {...}

---

它是一个组合，因为您的

帐户

对象必须有一个与之关联的

所有者

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

但根据常见的业务逻辑，可能总是希望与所有者建立一个帐户。没有所有者的帐户将毫无意义

---

合成是聚合的更严格版本。聚合只是表示“有一个”，但您可以认为组合更严格，或者必须创建一个对象（在您的情况下是

帐户

对象）

它是一个组合，因为您的

帐户

对象必须有一个与之关联的

所有者

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

但根据常见的业务逻辑，可能总是希望与所有者建立一个帐户。没有所有者的帐户将毫无意义

---

合成是聚合的更严格版本。聚合只是表示“有一个”，但您可以认为组合更严格，或者必须创建一个对象（在您的案例中是

帐户

对象）

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

在这种关系中，

所有者

对象通常是（或者可能是）多个

帐户

对象的聚合或组合，区别在于删除

所有者

对象是否强制删除其

帐户

对象，即。，

帐户

对象的生存期是否取决于所属

所有者

对象的生存期

帐户

对象在代码中有一个指向其所属

所有者

对象的链接也是很常见的，但我认为大多数人不会将该链接视为组合或聚合。在这种情况下，

Owner

对象实际上是

Account

对象的组合，并且

Account

中的

Owner

字段不允许为空。但事实并非如此。你的选择

---

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

关系是聚合还是组合是您在设计中的选择

在这种关系中，

所有者

对象通常是（或者可能是）多个

帐户

对象的聚合或组合，区别在于删除

所有者

对象是否强制删除其

帐户

对象，即。，

帐户

对象的生存期是否取决于所属

所有者

对象的生存期

帐户

对象在代码中有一个指向其所属

所有者

对象的链接也是很常见的，但我认为大多数人不会将该链接视为组合或聚合。在这种情况下，

Owner

对象实际上是

Account

对象的组合，并且

Account

中的

Owner

字段不允许为空。但事实并非如此。你的选择

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

• 聚合有三种：无、共享和组合
• 组合聚合或组合在UML标准中有严格的定义——当项目实例的生命周期受到容器或关联生命周期的限制时，它就是组合。那可能是你的案子？但根据标准，组合也假设关联多重性为一对多（一端为1，另一端为0…*），这里没有！而你是从物品中寻址容器，这是不可能合成的
• 共享聚合没有严格定义。通常是一个类拥有另一个类的实例。但这不是一条规则，只是一种传统。你有这个案子。苏，你可以把它命名为共享聚合。但你不必。
  • （通常，

    shared aggregation

    被简单地命名为

    aggregation

    ，但这只是一个错误。为了缩短时间，您可以将其命名为

    shared

    ）
• 如果您没有合成，并且确定没有共享聚合，则使用“无聚合”。所以，你也可以使用它

因此，可以将您拥有的命名为共享聚合或无聚合（后者越好）。但你还有一个可能性。这里您拥有的是

分类器拥有的端

。当一个类通过引用或直接拥有另一个类的实例时。在UML标准中，它也被命名为

atribute

。并显示为虚线结束

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

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

在右边可以使用空菱形、箭头、圆点或它们的任意组合。IMHO，B型是最好的。C也可以

您可以调用关联共享聚合或无聚合。 你应该把你的协会称为一个有点的协会。

• 聚合有三种：无、共享和组合
• 组合聚合或组合在UML标准中有严格的定义-当项目实例的生命周期受到容器或关联生命周期的限制时，它是组合的