C# 带有 UML 类图的组合和聚合示例

composition and aggregation example with UML class diagram

提问by Mefhisto1

i can't seem to understand completely the difference between aggregation and composition in a code.

我似乎无法完全理解代码中聚合和组合之间的区别。

Client <.>---->BankAccount

客户<.>---->银行账户

(this is supposed to be Client - BankAccount composition class diagram).

（这应该是Client - BankAccount 组合类图）。

So in this example, Client has a bank account, so this means, when a client object dies, his bank account object dies too. Does this mean, that we have to have a BankAccount object within Client class ?

所以在这个例子中，客户有一个银行账户，所以这意味着，当客户对象死亡时，他的银行账户对象也会死亡。这是否意味着我们必须在 Client 类中有一个 BankAccount 对象？

Class Client
{

    BankAccount acc = new BankAccount();

    public void addMoneyToBankAccount(decimal amount)
    {         
        acc.AddMoney(amount);
    }

    public decimal CheckBalance()
    {
        return acc.CheckAccountBalance();
    }

}

So, is this composition in code ? What would aggregation look like in this example? Sorry for the newbie question, please correct me if the code was wrong. Thanks in advance.

那么，这是代码中的组合吗？在这个例子中聚合会是什么样子？很抱歉新手问题，如果代码错误，请纠正我。提前致谢。

采纳答案by One Man Crew

Yes, What you do is call composition, if you want to do aggregation you to it like this:

是的，你所做的是调用组合，如果你想像这样聚合你：

Class Client
{

    BankAccount acc;

    public Client(BankAccount p_acc)
    {
      acc=p_acc;
    }

    public void addMoneyToBankAccount(decimal amount)
    {         
        acc.AddMoney(amount);
    }

    public decimal CheckBalance()
    {
        return acc.CheckAccountBalance();
    }

}

Aggregation:

聚合：

If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12+ months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example.

如果继承给我们“is-a”而组合给我们“part-of”，我们可以争辩说聚合给我们一个“has-a”关系。在聚合中，部分的生命周期不是由整体管理的。为了更清楚地说明这一点，我们需要一个例子。在过去的 12 个月以上，我一直参与 CRM 系统的实施，所以我将使用其中的一部分作为示例。

The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond.

CRM 系统有一个客户数据库和一个单独的数据库，该数据库保存一个地理区域内的所有地址。在这种情况下，聚合是有意义的，因为客户“拥有”地址。说地址是客户的“一部分”是没有意义的，因为它不是。这样想一想，如果客户不复存在，地址呢？我认为它不会停止存在。聚合在 UML 图上显示为未填充的菱形。

As I said at the beginning of the answer, this is my take on composition and aggregation. Making the decision on whether to use composition or aggregation should not be a tricky. When object modelling, it should be a matter of saying is this 'part-of' or does it 'have-a'?

正如我在答案开头所说的，这是我对组合和聚合的看法。决定是使用组合还是聚合不应该是一个棘手的问题。在对象建模时，应该说这是“一部分”还是“具有”？

回答by Dzmitry Martavoi

Yes, you are right. This is a simple composition.

你是对的。这是一个简单的组合。

For an aggregation, your Client class should keep reference for BankAccount class, but should not control it's object lifetime.

对于聚合，您的 Client 类应该保留对 BankAccount 类的引用，但不应该控制它的对象生命周期。

class Client
{
     private readonly BankAccount _account;

     public Client(BankAccount account)
     {
         _account = account;
     }

     //...
}

After Client object will be destroyed, BankAccount object used within can be assigned for an another Client.

Client 对象被销毁后，可以将其中使用的 BankAccount 对象分配给另一个 Client。

回答by Anirudha

Your client-BankAccount code is a compositionrelationship

您的客户-BankAccount 代码是一种composition关系

Your code satisfies all the properties of composition

您的代码满足组合的所有属性

->the lifetime of the part classifier(BankAccount) is dependent on the lifetime of the whole classifier(Client).

->部分分类器（BankAccount）的生命周期取决于整个分类器（Client）的生命周期。

->data usually flows in only one direction (that is, from the whole classifier(Client) to the part classifier(BankAccount).

->数据通常只向一个方向流动（即从整个分类器（Client）到部分分类器（BankAccount））。

---

---

Aggregation can be represented by passing BankAccount to client as an argument to a method

聚合可以通过将 BankAccount 作为方法的参数传递给客户端来表示

So,this code is Aggregation

所以，这段代码是聚合

class client
{
    public bool updateAccount(BankAccount ba){....}
}

As you can see it satisfies all the properties of Aggregation

如您所见，它满足聚合的所有属性

->it can exist independently of client

->它可以独立存在 client

->Data flows from the whole classifier(client) to the part(BankAccount)

->数据从整个分类器( client)流向部分( BankAccount)

回答by PapaSmurf

This explanation from IBMis helpful to me:

IBM 的这个解释对我很有帮助：

For example, we can think of Car as a whole entity and Car Wheel as part of the overall Car. The wheel can be created weeks ahead of time, and it can sit in a warehouse before being placed on a car during assembly. In this example, the Wheel class's instance clearly lives independently of the Car class's instance. However, there are times when the part class's lifecycle is not independent from that of the whole class — this is called composition aggregation. Consider, for example, the relationship of a company to its departments. Both Company and Departments are modeled as classes, and a department cannot exist before a company exists. Here the Department class's instance is dependent upon the existence of the Company class's instance.

例如，我们可以将 Car 视为一个整体，将 Car Wheel 视为整个 Car 的一部分。车轮可以提前几周制造，并且可以在组装期间放置在汽车上之前放在仓库中。在这个例子中，Wheel 类的实例显然独立于 Car 类的实例。然而，有时部分类的生命周期并不独立于整个类的生命周期——这称为组合聚合。例如，考虑公司与其部门的关系。Company 和 Departments 都被建模为类，并且在公司存在之前部门不能存在。这里 Department 类的实例依赖于 Company 类实例的存在。

So to me, the creator/destroyer life cycle (new, release) for a composition goes inside an instance; an aggregation must have the option instead to addObject and the method simply save the object id as an attribute of itself. So in the above Client and Bank Account example, it's really up to the business to determine if an Account can exist even if the Client record is destroyed (orphaned accounts) If it is aggegator, you would have Client methods:

所以对我来说，作品的创建者/破坏者生命周期（新的、发布的）在一个实例中；聚合必须有选项来代替 addObject 并且该方法只是将对象 ID 保存为自身的属性。所以在上面的客户和银行账户示例中，即使客户记录被销毁（孤立账户），确定一个账户是否可以存在真的取决于业务如果它是聚合器，你将拥有 Client 方法：

Class Client {
- (void) addToAccount:(BankAccount *)acc;
- (void) removeFromAccount:(BankAccount *)acc;
}

and the close account method would be part of the BankAccount object instance, since it can exist independently from the Client.

并且关闭帐户方法将是 BankAccount 对象实例的一部分，因为它可以独立于客户端存在。

versus the composition method which requres the Client to exist, and if the Client ceases to exist, all the accounts belonging to that account owner are deleted. Therefore, you would ask the Client object to create you an account:

与要求客户存在的组合方法相反，如果客户不复存在，则属于该帐户所有者的所有帐户都将被删除。因此，您会要求 Client 对象为您创建一个帐户：

Class Client {
- (BankAccount *) openAccount;
- (BOOL) closeAccount:(BankAccount *)acc;
}