It's important to understand why we should even bother with using more than once relationship line. The most obvious reason is to describe parent-child relationship between classes (when parent deleted all its child’s are deleted as a result), but more impotently, we want to distinguish between simple association and composition in order to place implicit restrictions on the visibility and propagation of changes to the related classes, a matter which plays an important role in understanding and reducing system complexity.

协会

描述类之间静态关系的最抽象的方法是使用Association链接，它简单地说明两个或多个类之间存在某种类型的链接或依赖关系。

弱协会

类a可以链接到类b，以显示其方法之一包含类b实例的参数，或返回类b实例。

强大的协会

类a也可以被链接到类b，以显示它持有对类b实例的引用。

聚合(共享关联)

在类a(整体)和类b(部分)之间存在部分关系的情况下，我们可以更具体地使用聚合链接而不是关联链接，强调类b也可以由应用程序中的其他类聚合(因此聚合也称为共享关联)。

需要注意的是，聚合链接并没有以任何方式说明ClassA拥有ClassB，也没有说明两者之间存在父子关系(当父类删除其所有子类时，其结果也将被删除)。事实上，恰恰相反!聚合链接通常用于强调ClassA不是ClassB的独占容器，因为实际上ClassB有另一个容器。

聚合vs .关联 关联链接在任何情况下都可以取代聚合链接，而聚合不能在类之间只有“弱链接”的情况下取代关联，即类a有包含类b参数的方法，但类a不包含对类b实例的引用。

马丁·福勒认为聚合链接根本不应该使用，因为它没有附加价值，而且会扰乱一致性，引用吉姆·拉姆博的话:“把它看作建模安慰剂”。

组合(非共享关联)

我们应该更具体地使用复合链接，在这种情况下，除了类a和类b之间的部分关系之外——两者之间有很强的生命周期依赖关系，这意味着当类a被删除时，ClassB也会被删除

复合链接表明一个类(容器，整体)对其他类(部分)具有独占所有权，这意味着容器对象及其部分构成了父子关系。

与关联和聚合不同，在使用组合关系时，组合类不能作为组合类的返回类型或参数类型出现。因此，对组合类的更改不能传播到系统的其余部分。因此，随着系统的增长，组合的使用限制了复杂性的增长。

测量系统复杂性

System complexity can be measured simply by looking at a UML class diagram and evaluating the association, aggregation, and composition relationship lines. The way to measure complexity is to determine how many classes can be affected by changing a particular class. If class A exposes class B, then any given class that uses class A can theoretically be affected by changes to class B. The sum of the number of potentially affected classes for every class in the system is the total system complexity.

你可以在我的博客上阅读更多: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

我想说明如何在Rails中实现这三个术语。ActiveRecord将两个模型之间的任何类型的关系称为关联。在阅读文档或文章时，人们不会经常发现术语组合和聚合与ActiveRecord相关。通过向类的主体中添加一个关联类宏来创建关联。其中一些宏是belongs_to, has_one, has_many等。

If we want to set up a composition or aggregation, we need to add belongs_to to the owned model (also called child) and has_one or has_many to the owning model (also called parent). Wether we set up composition or aggregation depends on the options we pass to the belongs_to call in the child model. Prior to Rails 5, setting up belongs_to without any options created an aggregation, the child could exist without a parent. If we wanted a composition, we needed to explicitly declare this by adding the option required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

在Rails 5中，这一点被改变了。现在，声明belongs_to关联在默认情况下创建了一个组合，子元素不能没有父元素而存在。所以上面的例子可以重写为:

class Room < ApplicationRecord
  belongs_to :house
end

如果我们想要允许子对象在没有父对象的情况下存在，我们需要通过选项optional显式地声明这一点

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

正如其他人所说，关联是对象之间的关系，聚合和组合是关联的类型。

从实现的角度来看，聚合是通过引用类成员来获得的。例如，如果类A聚合类B的一个对象，你会有这样的东西(在c++中):

class A {
    B & element;
  // or B * element;
};

聚合的语义是，当对象A被销毁时，它所存储的对象B仍然存在。当使用组合时，你有一个更强的关系，通常通过按值存储成员:

class A {
    B element;
};

在这里，当一个A对象被销毁时，它所包含的B对象也将被销毁。最简单的方法是按值存储成员，但你也可以使用智能指针，或在析构函数中删除成员:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

重要的一点是，在组合中，容器对象拥有被包含的对象，而在聚合中，它引用它。

联想是关系的广义概念。它包括组合和聚合。

组合(混合)是一种将简单对象或数据类型包装成单个单元的方法。组合是许多基本数据结构的关键构建块

聚合(将许多事物形成一个集群)不同于普通的组合，因为它不意味着所有权。在组合中，当拥有的对象被销毁时，包含的对象也被销毁。总的来说，这并不一定正确。

记住区别的技巧:

“有一个”:聚合 “局部”:comPOsitoin “是一个”:继承

现在让我们观察下面的图像

类比:

合成:下图是图像合成，即使用单独的图像合成一张图像。

聚合:图像在单一位置的集合

例如，A大学有多个系，每个系都有一些教授。如果大学关闭，这些部门将不复存在，但这些部门的教授将继续存在。因此，一所大学可以被看作是一个系的组成部分，而系则是教授的集合。此外，教授可以在一个以上的部门工作，但一个部门不能属于一所以上的大学。

我知道这个问题被标记为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的作者，并在上面添加了相关帖子的链接以获取更多信息。

    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.