PHP Magazine

As I got into Java seriously, I decided to give several Design Patterns books I own yet another try – I have skimmed through GoF’s master-piece number of times, but being a PHP programmer in PHP4 age, I just had no incentive to study patterns any deeper, as there clearly was no option to apply them. PHP5 is better wrt OO-tion but still looks like a toy.

Overall, I don’t understand the whole idea of implementing simple and easy-to-learn language, get popular, and then redesign the language to include all the goodies from “real languages like C/C++, Java”. But that’s topic for another post, I guess

So, now when I have a little more time to experiment with Java, and as it is as object-oriented as one might dream, I wanted to study patterns in details. I plan to post number of articles later this month, but for now, I wanted to capture one (important if you are planning to use UML and Patterns) simple concept – that’s difference between Aggregation and Composition. As simple as it might seem, there quite a lot of people who don’t understand it.

First of all, both Aggregation and Composition are Associations, and actually share characteristics, so I wouldn’t bother you with “has a”, “is a”, “is part of” cliches, which aren’t as helpful as it’s believed.

Very good definition of Aggregation, goes as following:

Aggregation is a whole/part association where a client object contains one or more server objects, but the client object can be defined with or without the creation of the server object. For instance, a car can contain golf clubs in its back trunk but the car is still a car with or without the golf clubs.

Let me translate. Aggregation is a “whole/part” association, and is used to describe object relationship where object A (client, aggregate, whole) contains object(s) B (server, component, part). Here, important word is “contains” – client literally contains the server object(s), it’s not composed of them.

Actually, that’s the sole difference between Aggregation and Composition, where later is a special case of former.

Before I provide some code examples, here is similar definition of Composition (do compare it with definition of Aggregation):

Composition is a stronger whole/part association where a client object is composed of one or more server objects, such that without the creation of the one or more server objects the client object could not be created. For instance, a car’s composition consists of an engine among other objects. However, the car would not be considered a car if it did not have an engine.

So, Aggregation vs. Composition is really a matter of control over life-cycle of parts within the whole. With Aggregation you can attach parts to whole at any time – for the whole to be initialized presence of parts that the whole might contain is not required. With Composition you have another story: since parts constitute the logical whole with the main object i.e. object is considered to be the sum of all its parts, you have to initialize parts at a time the container object is initialized.

Let’s have a look at examples.

As Aggregation refers to containment, and in Java code might look as following:

import java.util.ArrayList;
 
public class Aggregation {
    public static void main(String[] args)
    {
        Player Kaka = new Player();
        Team team = new Team();
        team.addPlayer(Kaka); // Kaka is now contained!
    }
}
 
/**
 * Client, Aggregate, Whole
 */
class Team {
    private ArrayList players;
 
    public Team() {
        // player list is empty, we can attach players via addPlayer(), so
        // that team CONTAINS players, however our team object is not dependant
        // on players for initialization - we can initialize Team objects even
        // if we have no intention to put players into them
        players = new ArrayList();
    }
 
    public void addPlayer(Player p)
    {
        players.add(p);
    }
}
 
/**
 * Dump Part class
 */
class Player {}

As you see Team object can exist without any players, and we can attach Player objects at any point after Team’s initialization.

Now, lets turn our attention to Composition example. Here parts should be initialized (generally within constructor of container class) prior to full initialization of container. Do understand that decision on which association is more appropriate depends on our aims, and we can re-write the Team/Player example to express composition if we believe that Team is composed of Players (so no entity could be called Team if it hasn’t got players):

import java.util.ArrayList;
 
public class Composition {
    public static void main(String[] args)
    {
        // player objects life-cycle is totally under container class controll
        Team team = new Team();
    }
}
 
/**
 * Client, Aggregate, Whole
 */
class Team {
    private ArrayList players;
 
    public Team() {
        players = new ArrayList();
        players.add(new Player());
    }
}
 
/**
 * Dump Part class
 */
class Player {}

As you see the difference is more conceptual. Indeed, when it comes to code, we can use the same constructs (member variables in this case) quite differently. If we have Aggregation in mind, then our container class can hold/contain components, while it doesn’t interested in initialization of those components (and destruction – which is not an issue in Java, due to garbage collection, but should be taken into consideration for, say, C++). If what we mean is Composition, then our container object is literally composed of those parts, and as such initializes them at construction time.

What I want to stress: despite the fact that difference between Aggregation and Composition might be academical at times, their conceptual difference is not that small. And on conceptual level you should understand what you are dealing with. You might be wrong thinking that Aggregation is a better abstraction for a Team/Player concept, but you should understand what aggregation means.

Sorry for such a lengthy explanation of what in essence is quite a simple concept.