Composition versus Aggregation

When trying to understand the relationships between objects, the discussion of aggregretation versus composition always comes up. For completeness, a third relationship should be mentioned, association. By far the best discussion of this topic can be found here. The conclusion reached by the author is as follows:

COMPOSITION: If destroying the whole destroys (or renders meaningless) the parts, then we have a composition.

AGGREGATION: If destroying the components destroys (or renders meaningless) the whole, then we have an aggregation.

Composition EXAMPLE: Destroying a database destroys its tables. But destroying the tables of a database does not destroy the database.

Aggregation EXAMPLE: Dismantling the group "Simon and Garfunkel" does not destroy Paul or Art. But destroying Paul and Art would be the end of the group "Simon and Garfunkel."

Martin Fowler added this observation:

This is a messy part of the UML. Aggregation is there for reasons that are more due to the interpersonal dynamics of building standards than any technical reason. I recommend that you ignore aggregation. Composition is occasionally useful, but I wouldn't worry about it too much unless you want to be a really fancy UMLer. On the whole aggregation and composition cause far more confusion than they are worth.

From another discussion

Associations are only one type of relationship in UML. We will consider two more types of other UML relationships in this article and leave the others for a later time. Aggregation and composition relationships are really just different flavors of an association. An aggregation is a type of association that represents a relationship in which objects of one class represent parts of objects of another class; you will hear people referring to aggregation as a whole-part relationship. An aggregation relationship is shown by a solid line with an unfilled diamond at the end closest to the class that represents the "whole" in the relationship.

So, what does aggregation look like in source code? Well, the answer is, "It depends on who you ask." Aggregation is a somewhat vague concept that conveys a life-cycle dependency relationship. Some use the convention that aggregation means that the Whole class is responsible for creating and destroying (leaving for the garbage collector) the objects of the Part class. Others use the relationship far more loosely. In the end, it's probably best to explicitly agree on a convention in your own team to avoid confusion.

There is a stronger version of the aggregation relationship called composition. A composition relationship is the same as an aggregation except that a Part object can belong only to one Whole object at any one time. At least this time we know we have to write some code to check that constraint.