这是一个关联或聚合的案例吗？

Question

我找到了一个关于学生如何在一系列课程中注册的Java示例：

学生----- ------需要课程

并且在示例中定义为Association，但为什么它不能聚合？因为我看到每个班级都可以独立存在。如何区分两者？

在上面的例子中，我处理的是一个学生有一系列课程作为属性的模式，而Course也有一个学生数组;所以在这种情况下是关联，因为它们都是相关的，而聚合是因为一个包含在另一个中？

Answer 1

这不是聚合，因为课程不是学生的集合，学生不是课程的集合。这是一个简单的多对多关联。我还看到这个模型有一个关联类“enrolls”，它封装了允许学生注册课程所需的方法和数据。聚合的一个例子是车身应用程序中汽车的存在方式。汽车有可拆卸的零件（轮胎，发动机，底盘等），它们可以独立存在，但知道特定汽车上仍然存在哪些零件会很有用。

Answer 2

UML知道不同（子）类型的关联，而聚合只是其中之一。 关联只是意味着源与目标之间存在某种关系。

你可能的意思是聚合和组合之间的区别。 在聚合中，聚合实体可以不存在整体;在作文中，他们不能。

Answer 3

简单地说，聚合表示包含，其中内容可以从容器中删除并且单独存在（当它不能时，它是一个组合）。

这里不是遏制，学生不包含在课堂中，学生不包含课程。因此，这是一个简单的关联

2条评论：

• 当一个对象包含在另一个对象中时，它不能包含在其他几个对象中。因此，对于聚合，容器端的多重性将为1或0-1。在这里，双方都是0-*，永远不能聚合。
• 聚合只是一种特殊的关联案例，所以无论如何，如果你建立关联，你总是对的（虽然在某些情况下不是很精确）

Answer 4

您应该首先定义名称。

什么是课程？主题？还是主题+讲师？还是主题+讲师+课堂/时间？

让我们将它们命名为主题，课程，课程

我们有Lectors，Classrooms，Students。

这是图表。 （请注意，连接上没有任何错误意味着连接可以在两侧导航）

因此，这里的学生课程连接是多对多依赖。您可以通过在两端或其中一个上进行聚合（例如列表）来实现它。第一个变体更难改变，但更容易阅读。但是你必须至少在一方有一个聚合。