The big idea: Composition and aggregation are both has-a: one object holds another as an attribute.
The difference is ownership — whether the part can survive without the whole.
| Composition | Aggregation | |
|---|---|---|
| Relationship | Owns — part of | Uses — has a reference to |
| Part survives the whole? | No — destroyed with it | Yes — exists independently |
| Example | A House and its Rooms | A Course and its Students |
| Created | Usually by the whole, inside it | Passed in from outside |
| UML | Filled diamond ◆ | Hollow diamond ◇ |
The survival test: Delete the whole. Does the part still make sense on its own?
Delete a house — its rooms are meaningless, so that is composition. Delete a course — its students still exist and are enrolled elsewhere, so that is aggregation.
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
The tell in the code
- The whole constructs the part inside itself → composition
- The part is passed in as a parameter → aggregation
- Composition: nothing outside holds a reference to the part
- Aggregation: the part is referenced elsewhere too, and must not be destroyed
Stop wasting time on topics you know
Our AI identifies your weak areas and focuses your study time where it matters. No more overstudying easy topics.
Looser coupling
- The whole depends on the part's interface, not its internals
- Changing the part's implementation breaks nothing
- Inheritance exposes the parent's internals to every child
Changeable at run time
- A part can be swapped while the program runs
- A superclass is fixed the moment the object is created
- So behaviour can be reconfigured rather than recompiled
No inherited baggage
- You get only what you asked for
- Inheritance brings everything the parent has, wanted or not
- Including members that make no sense on the child
Prefer composition over inheritance: The standard advice, and the reason is the is-a test: inheritance is right only when the child genuinely is a kind of the parent.
When it is reached for merely to reuse code, composition does the same job with far less coupling.
How this is tested — you must classify a relationship using ownership, and justify composition against inheritance. It comes up two ways:
Paper 2 — working with code
- Explain composition and aggregation, 3-4 marks
- Classify a given pair of classes
- State which UML diamond applies
Paper 2 — the algorithmic-thinking question
- Design classes for a scenario and justify the relationships
- Explain why inheritance would be wrong
The classic trap: Treating any has-a as composition. The distinction is ownership: if the part survives the whole being deleted, it is aggregation. Apply the survival test explicitly.
A school system has Department, Teacher and Classroom. Explain which relationships are composition and which aggregation, justifying each.
Model answer plan
See the mark-by-mark plan — for / against / judgement, with marking guidance — in study mode.