Composition and aggregation are both “has-a” relationships between classes, but they differ in ownership and object lifecycle. In composition, the part depends on the whole; in aggregation, the part can exist independently.
The Reasoning
Both relationships allow one class to hold references to objects of another class. This supports object-oriented programming (OOP) by modelling systems as interacting objects rather than placing all data and behaviour in one class.
Composition represents strong ownership. The whole object controls the lifecycle of its component objects: if the whole is destroyed, its parts normally cease to exist as part of that model. For example, a House may be composed of Room objects created and managed by the House.
Aggregation represents weaker ownership. The related object exists independently and may be shared with, or reassigned to, another object. For example, a Team may aggregate Player objects, because a player can exist without that particular team and can transfer to another team.
| Feature | Composition | Aggregation |
|---|---|---|
| Relationship | Strong “has-a” relationship | Weak “has-a” relationship |
| Ownership | Whole owns and manages the parts | Whole refers to independently existing objects |
| Lifecycle | Part depends on the whole | Part can exist without the whole |
| Sharing | Part is normally exclusive to one whole | Object may be shared or reassigned |
| UML notation | Filled diamond at the whole | Hollow diamond at the aggregate |
| Example | House and Room | Team and Player |
A common misconception is that composition simply means one object is stored inside another. The decisive issue is not code placement but lifecycle dependency and ownership.
Exam Technique
For IB Computer Science B3.2, define both relationships, identify which object is the whole, and justify your classification using lifecycle independence. In UML questions, place the diamond at the whole or aggregate class, not at the part class.
