为什么关联，聚合和组合使用的方式与本例中的使用方式相同？

Question

我理解三者之间的差异（或者至少我认为我这样做）。我知道还有很多其他类似的问题，例如one。

我正在寻找gliffy.com的一个例子，我很沮丧地理解为什么使用它们的方式使用了一些关系。我想我真正努力的是了解何时使用关联。

我遇到的一些问题是：

1. 为什么客户订单和客户信用卡是一个不是像客户地址一样的聚合？
2. 如果没有订单，ItemOrder将不存在，为什么Order-ItemOrder不是组合？
3. 为什么ItemOrder-Item不聚合？

Answer 1

为了回答这些问题，重要的是要知道绘制这个类图的原因。只有作者知道，但也许它只是一个gliffy功能的演示？否则，也许这个模型中的类对应于源代码中的类，用面向对象的语言（如Java或C＃）编写，并且该图旨在深入了解这些类之间的关系。

1. 为什么客户订单和客户信用卡是关联而非聚合，如客户地址？

   显然，作者并不认为这些关系是＆＃39;的一部分。关系。也许客户在源代码中没有对Orders或CreditCards的任何引用。也许地址信息属于客户类的责任，但订单和信用卡信息不属于。

2. 为什么Order-ItemOrder没有给定如果没有订单就不存在ItemOrder？

   也许作者只使用UML的一个子集，并且不按惯例使用合成。也许作者认为聚合和组合之间的区别对于此图的目的来说并不重要。

3. 为什么ItemOrder-Item不聚合？

   显然，作者并不认为这种关系是一种关系的一部分。也许作者保留了聚合类型的关系来表示一种特定的编程语言结构，在这种情况下，源代码中没有使用它。也许作者认为界面永远不能在另一个类中聚合。

顺便说一下，ItemOrder和ShoppingCart之间的聚合显然是错误的。我认为钻石应该是关系的另一面。

Answer 2

简单地忘记共享/复合聚合。它确实具有较低的语义，只会导致无论是否需要以及使用对错的地方都是徒劳的讨论。只需使用（并解释）关联和多重性。

（几乎）只能以有意义的方式使用聚合的地方是DB外键（强制删除）和内存（免费未使用）管理。