我有一个专辑类和一个Track类。曲目可以独立于专辑而存在，但是没有任何曲目就不能存在专辑。
我认为这是一个聚合，因为在销毁相册时不会销毁曲目。但是属于特定专辑的特定曲目将会被专辑破坏...所以有人可以更清楚地说明这一点吗？
此外，这是作业，但这不是实际问题。我们正在进行大量的建模练习，这是一个单一的关联链接。
答案 0 :(得分：6)
在非家庭作业领域，这是用例决定设计的地方。
如果曲目是独立的实体，而专辑是曲目的集合，那很好。但是，在这样的系统下，删除相册并不意味着删除曲目。
...除非您有“删除专辑曲目”选项
...或者您决定仅在所有相册不再包含该曲目时删除曲目。
...你有一张无法删除的“未分类曲目”专辑。
在您确定数据模型支持您可能希望支持的确切使用模式之前，您需要确定打算如何使用应用程序。
答案 1 :(得分：4)
相册是轨道的集合。 Track 与零个或多个相册相关联。存在诸如没有专辑的曲目之类的东西。因此，专辑是曲目的聚合。一个曲目可以在多个专辑中（概念上;考虑Greatest Hits集合！），因此删除曲目显然是不合适的，因为它的第一张专辑被删除了。
如果一个对象可以同时存在于多个集合中，或者可以独立于该集合存在，或者在集合时不应该被销毁，则它是聚合。
为什么要在销毁专辑时销毁曲目？如果曲目有零或一个专辑，并且一旦添加就永远不会从专辑中删除，那么合成可能更合适 - 但这更像是聚合，而你的“属于专辑“可能不会在正确的轨道上销毁。”
组合和聚合主要是出于这个原因分开的：你需要知道什么时候假设一个对象因为包含它的集合而变得未被引用是不安全的（假设聚合不是安全的，不是对于一个组合），如果你想破坏它只是因为它的集合消失了，它可能是一个组合 - 但如果不是你如何使用它，某些东西可能在某个地方出错。
答案 2 :(得分：2)
从问题的第一部分开始，我会说这不是作文。如果曲目可以比其专辑更长，那么根据定义，它的生命周期不受专辑的生命周期的支配。因此，它不是构图。
我甚至怀疑它是否是聚合 - 但那取决于你对聚合的特定定义，因为它在UML规范中的定义非常糟糕。
根据您提供的信息，我很可能会成为一个简单的模型：许多二元关联，基于您尝试捕获的域规则：
然而，你有一些问题我并不理解：
但属于特定专辑的特定曲目将会被专辑销毁......
你能详细说明吗？将已销毁的曲目与其专辑的曲目区别开来的是什么？
第h