关联、聚合和组合之间的区别是什么? 请从实施的角度加以说明。


当前回答

在面向对象编程中,类是相互关联的。这意味着它们的实例相互调用方法。因此,如果一个类的实例调用另一个类的方法,它们是相关的,通常我们用ASSOCIATION来建模这种关系。 例如,在下面的代码片段中,Customer类与Order类相关联。她/他取消了订单。

class Customer {
        private Order[] orders;
        public boolean removeCart() {
                for (int i = 0 ; i < orders.length ; i++) {
                        orders[i].cancel();
                }
        }
}

AGGREGATION意味着一个类拥有另一个类的一些实例。它只不过是联想,马丁·福勒建议不要使用它。因为当一个类与另一个类相关联时,它有一个对该类的引用来调用该类上的方法。

但是COMPOSITION是关联的一个有意义的子集。这意味着一个类是由其他一些类组成的。例如,我们有一个学生类,由其他一些类组成,如ReportCard。我们知道成绩单是非常依赖于学生的,如果我们从系统中删除了学生,他们的成绩单也应该被删除。

其他回答

摘自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
};

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

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

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

关联、聚合、组合

关联、聚合、组合都是有关系的。

聚合和组合是关联的子集,它们更准确地描述了关系

与聚合无关的关系。一个对象可以通过构造函数、方法、setter传递和保存在类中…

成分依赖关系。对象由所有者对象创建

关联是sybtyping的另一种选择

摘自: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.

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

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

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