Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

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

请注意，术语聚合和组合已经在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)

我知道这个问题被标记为c#，但概念是非常一般的问题，就像这里的这个重定向。所以我将在这里提供我的观点(从java的角度来看，我更舒服)。

当我们想到面向对象的本质时，我们总是想到对象、类(对象蓝图)以及它们之间的关系。对象之间通过方法相互关联和交互。换句话说，一个类的对象可以使用另一个类的对象提供的服务/方法。这种关系被称为关联。

聚合和组合是关联的子集，这意味着它们是关联的特定情况。

In both aggregation and composition object of one class "owns" object of another class. But there is a subtle difference. In Composition the object of class that is owned by the object of it's owning class cannot live on it's own(Also called "death relationship"). It will always live as a part of it's owning object where as in Aggregation the dependent object is standalone and can exist even if the object of owning class is dead. So in composition if owning object is garbage collected the owned object will also be which is not the case in aggregation.

困惑吗?

组合示例:以一辆汽车为例，它的发动机是这辆汽车特有的(意味着它不能用于任何其他汽车)。Car和SpecificEngine类之间的这种关系称为Composition。Car类的对象如果没有SpecificEngine类的对象就不能存在，而如果没有Car类，SpecificEngine的对象就没有意义。简单地说，Car类单独“拥有”SpecificEngine类。

聚合示例:现在考虑类Car和类Wheel。Car需要一个Wheel对象来运行。这意味着Car对象拥有Wheel对象，但我们不能说没有Car对象，Wheel对象就没有意义。它可以很好地用于自行车，卡车或不同的汽车对象。

总结一下

总而言之，关联是一个非常通用的术语，用于表示一个类使用另一个类提供的功能。如果一个父类对象拥有另一个子类对象，并且没有父类对象，这个子类对象就不能有意义地存在，我们就说它是复合。如果可以，则称为聚合。

详情请点击这里。 我是http://opensourceforgeeks.blogspot.in的作者，并在上面添加了相关帖子的链接以获取更多信息。

我想这个链接可以帮到你:http://ootips.org/uml-hasa.html

为了理解这些术语，我记得我早期编程时的一个例子:

如果你有一个" chess board "对象它包含" box "对象那就是组合因为如果" chess board "被删除了盒子就没有理由再存在了。

如果你有一个'square'对象，它有一个'color'对象，正方形被删除了，'color'对象可能仍然存在，这就是聚合

它们都是关联，主要的区别是概念上的

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

https://www.linkedin.com/pulse/types-relationships-object-oriented-programming-oop-sarah-el-dawody/

Composition:是一种“part-of”关系。

例如，“发动机是汽车的一部分”，“心脏是身体的一部分”。

关联:是“has-a”类型的关系

例如，假设我们有两个类，那么这两个类被称为“has-a”关系，如果这两个实体为了某些工作而共享彼此的对象，同时它们可以不依赖彼此而存在，或者它们都有自己的生命期。

上面的示例显示了一种关联关系，因为Employee类和Manager类都使用彼此的对象，并且都有各自独立的生命周期。

聚合:是基于“has-a”关系，是一种特殊的关联形式

例如，“学生”和“地址”。每个学生必须有一个地址，所以学生类和地址类之间的关系将是“Has-A”类型的关系，反之亦然。