这些答案的问题在于，它们只说了一半:它们解释了聚合和组合是关联的形式，但没有说一个关联是否可能不是这两种形式。

基于对SO和一些UML文档的一些简要阅读，我收集到类关联有4种主要的具体形式:

A是由A组成的;没有A, B就不存在，就像家里的房间一样 聚合:A有A B;B可以没有A而存在，就像教室里的学生一样 依赖:A使用B;A和B之间没有生命周期依赖关系，比如方法调用参数、返回值或方法调用期间创建的临时对象 泛化:A是A

当两个实体之间的关系不是其中之一时，它可以被称为一般意义上的“关联”，并以其他方式进一步描述(注意，原型等)。

我的猜测是，“通用关联”主要用于两种情况:

when the specifics of a relationship are still being worked out; such relationship in a diagram should be converted as soon as possible to what it actually is/will be (one of the other 4). when a relationship doesn't match any of those 4 predetermined by UML; the "generic" association still gives you a way of representing a relationship that is "not one of the other ones", so that you aren't stuck using an incorrect relationship with a note "this is not actually aggregation, it's just that UML doesn't have any other symbol we could use"

摘自Robert Martin在comp.object中的一篇文章:

关联表示一个实例向另一个实例发送消息的能力。这通常是通过指针或引用实例变量实现的，尽管它也可以实现为一个方法参数，或创建一个局部变量。

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

聚合[…是典型的整体/部分关系。这与实例不能具有循环聚合关系(即部分不能包含其整体)的异常关联完全相同。

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

这是聚合的事实意味着Node的实例不能形成一个循环。因此，这是一个节点树，而不是节点图。

成分[…和聚合完全一样，只是“部分”的生命周期由“整体”控制。这种控制可以是直接的，也可以是传递的。也就是说，“整体”可以直接负责创造或破坏“部分”，或者它可以接受一个已经创建的部分，然后将它传递给其他某个整体，由其承担责任。

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

令人惊讶的是，关于关联、聚合和组合这三个关系概念之间的区别存在如此多的混淆。

请注意，术语聚合和组合已经在c++社区中使用，可能在它们被定义为UML类图中关联的特殊情况之前已经有一段时间了。

主要的问题是广泛的和持续的误解(甚至在专家软件开发人员中)，组合的概念意味着整体和它的部分之间的生命周期依赖关系，以至于部分不能没有整体而存在，忽略了这样一个事实，即也存在与不可共享部分的部分-整体-关联的情况，其中部分可以从整体中分离出来，并且在整体被破坏后仍然存在。

在我看来，这种困惑有两个根源:

In the C++ community, the term "aggregation" was used in the sense of a class defining an attribute for referencing objects of another independent class (see, e.g., [1]), which is the sense of association in UML Class Diagrams. The term "composition" was used for classes that define component objects for their objects, such that on destruction of the composite object, these component objects are being destroyed as well. In UML Class Diagrams, both "aggregation" and "composition" have been defined as special cases of associations representing part-whole relationships (which have been discussed in philosophy for a long time). In their definitions, the distinction between an "aggregation" and a "composition" is based on the fact if it allows sharing a part between two or more wholes. They define "compositions" as having non-shareable (exclusive) parts, while "aggregations" may share their parts. In addition they say something like the following: very often, but not in all cases, compositions come with a life-cycle dependency between the whole and its parts such that the parts cannot exist without the whole.

因此，尽管UML将术语“聚合”和“组合”放在了正确的上下文中(部分-整体关系)，但是他们并没有设法以一种清晰和明确的方式来定义它们，从而捕捉开发人员的直觉。然而，这并不奇怪，因为这些关系可以有很多不同的属性(和实现的细微差别)，开发人员对如何实现它们没有一致的意见。

请参见我对2009年4月SO问题的扩展回答。

c++社区中定义OOP对象之间“组合”的属性(这个信念仍然被广泛持有):两个相关对象(组合及其组件)之间的运行时生命周期依赖关系并不是“组合”的真正特征，因为在其他类型的关联中，我们也可以由于引用完整性而具有这种依赖关系。

例如，在一个SO回答中提出了以下“composition”的代码模式:

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

被调查者声称这是“合成”的特征，没有其他类可以引用/知道这个组件。然而，并非所有可能的“组合”情况都是如此。特别是，在汽车引擎的情况下，汽车的制造商(可能是在另一个类的帮助下实现的)可能必须引用引擎，以便在出现问题时能够联系汽车的所有者。

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

附录-关于StackOverflow上的组合与聚合的反复询问问题的不完整列表

[Apr 2009] Aggregation versus Composition [closed as primarily opinion-based by] [Apr 2009] What is the difference between Composition and Association relationship? [May 2009] Difference between association, aggregation and composition [May 2009] What is the difference between composition and aggregation? [duplicate] [Oct 2009] What is the difference between aggregation, composition and dependency? [marked as duplicate] [Nov 2010] Association vs. Aggregation [marked as duplicate] [Aug 2012] Implementation difference between Aggregation and Composition in Java [Feb 2015] UML - association or aggregation (simple code snippets)

摘自:Remo H. Jansen的《Beginning React: Learning TypeScript 2》。x -第二版”:

We call association those relationships whose objects have an independent life cycle where there is no ownership of the objects. Let's take a look at an example of a teacher and a student. Multiple students can be associated with a single teacher, and a single student can be associated with multiple teachers, but both have independent life cycles (both can create and delete independently). So, when a teacher leaves the school, we don't need to delete any students, and when a student leaves the school, we don't need to delete any teachers.

我们称这些关系为聚合，其对象具有独立的生命周期，但存在所有权，并且子对象不能属于另一个父对象。让我们以手机和电池为例。单个电池可以属于一个手机，但如果手机停止工作，我们从数据库中删除它，手机电池将不会被删除，因为它可能仍在工作。因此，在聚合中，虽然有所有权，但对象有它们的生命周期

我们使用术语组合来指代对象没有独立生命周期的关系，如果父对象被删除，所有子对象也将被删除。让我们以问题和答案之间的关系为例。一个问题可以有多个答案，答案不能属于多个问题。如果我们删除问题，答案将自动删除。

关联是两个独立的类之间的关系，关联可以是任何类型，比如one to one, one to may等等。它连接了两个完全独立的实体。

聚合是一种特殊形式的关联，它是类(或实体)之间的单向关系，例如钱包类和货币类。钱包里有钱，但钱不一定要有钱包，所以这是一种单向关系。在这种关系中，如果另一个条目结束，两个条目都可以存活。在我们的例子中，如果Wallet类不存在，并不意味着Money类不存在。

复合是聚合的一种受限形式，其中两个实体(或者可以说类)高度依赖于彼此。例如:人与心。人需要心脏才能生存，心脏也需要人体才能生存。换句话说，当类(实体)是相互依赖的，它们的生命周期是相同的(如果一个死了，另一个也死了)，那么它就是一个复合。如果人类职业不存在，心脏职业就没有意义。

成分: 一旦你摧毁了一个对象(学校)，另一个与之绑定的对象(教室)也会被摧毁。两者都不能独立存在。

聚合: 这与上面的(Composition)关联完全相反，在上面的关联中，一旦你杀死了一个对象(Company)，绑定到它的另一个对象(Employees)就可以独立存在。

协会。 组合和聚合是关联的两种形式。