Aggregation和Association在实现上的区别
The difference between Aggregation and Association in implementation
我已经阅读了很多关于对象关系的理论，但我仍然难以理解如何从实现的角度分离关联和聚合。
在这两种情况下，您都将对象 B 作为对象 A 中的数据成员，它在那里作为引用存在（与按值存在的组合不同）。那么这两种情况到底有什么区别呢？
我在某处读到一些 Java 大师认为聚合是一个完全抽象的概念，"placebo" 从 implementation/syntax 的角度无法区分（从关联）的情况，是正确的还是我错过了什么吗？
我同意，从实现的角度来看，关联和聚合看起来是一样的——正如您提到的，在这两种情况下，其中一个对象是另一个对象的数据成员。
我的理解是，您所询问的实现差异不会发生在对象级别，而是发生在应用程序设计级别：
如果通过实现差异您理解代码本身（对象放置在另一个对象中的方式），则没有区别。
但是如果我们将话题扩展到对象在应用程序中的使用方式，那么我们需要开始研究对象是否自给自足，它们是否可以服务于一个独特的、独立的功能与否。这还是实现
编辑 -> 补充说明如下：
我可能还不够清楚——我的意思是在这种情况下，实现可以从两个层面考虑：
表示 class 中对象的代码（保存对象引用的字段）
更广泛的代码（对象在其他 classes 中的使用方式或对象之间的依赖关系如何表示）
这两个都可以理解为 实现 ，但在不同的抽象级别上 - class 中的用法对于 是相同的聚合 和 组合，但对象关系在多个class 中实现 的方式会有所不同。
正确地说：UML 术语聚合（您可能指的是）是 composite aggregation。 UML 2.5 的第 110 页说：
composite - Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
如果您指的是共享聚合，请参见同一页。 110:
shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
tl;dr
区别很简单。如果聚合对象说再见，则必须销毁复合（聚合）对象。关联对象不关心（或者引用对象不会尝试杀死它）。
对于共享聚合：创建您自己的定义并将其连同其用法一起发布。
聚合与关联的实现通常没有区别，因为它们的语义差异通常与应用代码无关。
聚合是一种特殊形式的关联，具有部分-整体关系的预期含义，其中整体的部分可以与其他整体共享。例如，我们可以对 类 DegreeProgram 和 Course 之间的聚合进行建模，如下图所示，因为课程是学位课程的一部分，并且课程可以共享两个或多个学位课程（例如，工程学位可以与计算机科学学位共享 C 编程课程）。
以这种方式对 DegreeProgram 和 Course 之间的特殊关系进行建模传达了一些预期的含义，但不一定而且通常不会反映在实现代码中，这可能看起来如下：
class DegreeProgram {
private List<Course> courses;
...
}
我已经阅读了很多关于对象关系的理论，但我仍然难以理解如何从实现的角度分离关联和聚合。 在这两种情况下，您都将对象 B 作为对象 A 中的数据成员，它在那里作为引用存在（与按值存在的组合不同）。那么这两种情况到底有什么区别呢？ 我在某处读到一些 Java 大师认为聚合是一个完全抽象的概念，"placebo" 从 implementation/syntax 的角度无法区分（从关联）的情况，是正确的还是我错过了什么吗？
我同意，从实现的角度来看，关联和聚合看起来是一样的——正如您提到的，在这两种情况下，其中一个对象是另一个对象的数据成员。
我的理解是，您所询问的实现差异不会发生在对象级别，而是发生在应用程序设计级别：
如果通过实现差异您理解代码本身（对象放置在另一个对象中的方式），则没有区别。
但是如果我们将话题扩展到对象在应用程序中的使用方式，那么我们需要开始研究对象是否自给自足，它们是否可以服务于一个独特的、独立的功能与否。这还是实现
由你决定
编辑 -> 补充说明如下：
我可能还不够清楚——我的意思是在这种情况下，实现可以从两个层面考虑：
表示 class 中对象的代码（保存对象引用的字段）
更广泛的代码（对象在其他 classes 中的使用方式或对象之间的依赖关系如何表示）
这两个都可以理解为 实现 ，但在不同的抽象级别上 - class 中的用法对于 是相同的聚合 和 组合，但对象关系在多个class 中实现 的方式会有所不同。
正确地说：UML 术语聚合（您可能指的是）是 composite aggregation。 UML 2.5 的第 110 页说：
composite- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
如果您指的是共享聚合，请参见同一页。 110:
shared- Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
tl;dr
区别很简单。如果聚合对象说再见，则必须销毁复合（聚合）对象。关联对象不关心（或者引用对象不会尝试杀死它）。
对于共享聚合：创建您自己的定义并将其连同其用法一起发布。
聚合与关联的实现通常没有区别，因为它们的语义差异通常与应用代码无关。
聚合是一种特殊形式的关联，具有部分-整体关系的预期含义，其中整体的部分可以与其他整体共享。例如，我们可以对 类 DegreeProgram 和 Course 之间的聚合进行建模，如下图所示，因为课程是学位课程的一部分，并且课程可以共享两个或多个学位课程（例如，工程学位可以与计算机科学学位共享 C 编程课程）。
以这种方式对 DegreeProgram 和 Course 之间的特殊关系进行建模传达了一些预期的含义，但不一定而且通常不会反映在实现代码中，这可能看起来如下：
class DegreeProgram {
private List<Course> courses;
...
}