UML类图的组合和聚合示例

Question

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

客户<.> ----> BankAccount

(这应该是Client - BankAccount组合类图).

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

Class Client
{

    BankAccount acc = new BankAccount();

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

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

}

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

Answer 1

是的,你做的是调用组合,如果你想像这样聚合你:

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();
    }

}

聚合:

如果继承给我们'is-a'并且组合赋予我们'part-of',我们可以认为聚合给我们一个'has-a'关系.在聚合中,部件的生命周期不受整体管理.为了更清楚,我们需要一个例子.在过去的12个多月里,我参与了CRM系统的实施,因此我将以此为例.

CRM系统具有客户数据库和单独的数据库,该数据库包含地理区域内的所有地址.在这种情况下,聚合是有意义的,因为客户有一个"地址".说地址是"客户的一部分"是没有意义的,因为事实并非如此.以这种方式考虑,如果客户不再存在,那么地址呢？我认为它不会停止存在.聚合在UML图上显示为未填充的钻石.

正如我在答案开头所说,这是我对构图和聚合的看法.决定是否使用组合或聚合不应该是一个棘手的问题.在对象建模时,应该说这是"部分"还是"有"？

Answer 2

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

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

- > part classifier(BankAccount)的生命周期取决于整个分类器(Client)的生命周期.

- >数据通常只在一个方向上流动(即从整个分类器(Client)流向零件分类器(BankAccount).

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

所以,这段代码是Aggregation

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

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

- >它可以独立存在 client

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