composition and aggregation example with UML class diagram

Question

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).

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 ?

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.

Solution 1

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.

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.

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'?

Solution 2

Your client-BankAccount code is a composition relationship

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).

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

---

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

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

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

Solution 3

This explanation from IBM is helpful to me:

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.

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:

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.

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:

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

Solution 4

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.

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.

View more solutions