这是一个聚合或组合关联？

Question

我有一个Album类和一个Track类。曲目可以独立于专辑存在，但是专辑不能没有任何曲目存在。

我在想这是一个聚合，因为当专辑被销毁时曲目不会被销毁。但是属于特定专辑的特定曲目将随专辑销毁......所以有人可以更清楚地说明这一点吗？

此外，这是作业，但这不是真正的问题。我们正在做一个巨大的建模练习，这是一个单一的关联链接。

Answer 1

在非家庭作业的世界里，这是用例决定设计的地方。

如果曲目是独立的实体，专辑是曲目的集合，那很好。但是，在这样的系统下，删除专辑并不意味着删除曲目。

...除非你有一个选项“删除与专辑曲​​目”

...或者你决定，只有当所有的专辑都不再包含它的轨道将被删除。

...你有一个“未分类的曲目”专辑，无法删除。

听起来你需要确定你打算如何使用你的应用程序，然后再决定数据模型支持你可能想要支持的确切的使用模式。

Answer 2

一个专辑是一个轨道的集合。 A Track 与相关联的零个或多个专辑。存在没有专辑的轨道这样的事情。因此，专辑是轨道的汇总。一首曲目可以放在多张专辑（概念上，考虑Greatest Hits集合！），所以显然不适合销毁曲目，因为它的第一张专辑已被删除。

如果一个对象可以同时存在于多个集合中，或者可以独立于该集合而存在，或者在收集时不应该销毁，则这是一个聚合。

为什么在销毁相册时想要销毁曲目？如果曲目有零个或一个专辑，并且永远不会从添加到专辑中删除，则合成可能更合适 - 但这更像聚合，并且您的“属于特定专辑的曲目应该被销毁与专辑“可能不在正确的轨道上。

组合和聚合主要是出于这个原因分开的：你需要知道何时不安全地假设一个对象已经因为包含它的集合而被重新引用（这对于聚合来说是不安全的，而不是作曲），如果你想摧毁一些东西，只是因为它的收藏消失了，它可能是一个构图 - 但如果这不是你使用它的方式，那么某处可能出错了。

Answer 3

从你的问题的第一部分我会说这不是组成。如果一首曲目可能超过其专辑，那么按照其定义，其生命周期不受专辑的影响。所以它不是组成。

我甚至会质疑它是否是Aggregation - 但是这取决于您对Aggregation的特定定义，因为它在UML规范中的定义非常糟糕。

基于你给我最好的信息更可能模式为直多方面的：许多二进制协会，理由是你试图捕捉域规则上：

1. 每张专辑包括一个或多个曲目
2. 每个曲目可以出现在一个或多个专辑中。

但是有一点你的问题我真的不明白：属于一个特定的专辑将与册页被破坏

但具体曲目...

你能详细说明吗？什么区别与其专辑摧毁的轨道不是？

hth。