Programming technique · B3.2.4 · Higher level only
Composition and aggregation
Inheritance describes an is-a relationship. Composition and aggregation describe whole–part relationships: one object is built from, contains or uses other objects. The important difference is ownership and whether the part has a meaningful independent lifetime.
Start with the objects, not the terminology
Imagine a quiz system. Two Player objects already exist in the roster before a QuizSession begins. The session also needs an AnswerLog, but that log is created specifically for this one session.
Two kinds of whole–part relationship
Composition
Strong ownership. The whole is responsible for a part whose meaningful lifetime is tied to that whole in the software model.
Aggregation
Independent part. The whole groups or uses an object that already has its own identity and can remain meaningful without that whole.
UML rule: the diamond belongs at the whole end. Filled diamond = composition. Hollow diamond = aggregation.
Use several pieces of evidence
| Question | Composition evidence | Aggregation evidence |
|---|---|---|
| Independent identity? | Part has no meaningful independent role in this model. | Part already has its own identity. |
| Modelled lifetime? | Tied closely to the whole. | Can continue before/after or move between wholes. |
| Creation responsibility? | The whole often creates the part. | The whole often receives a reference to an existing object. |
| Sharing/reassignment? | Usually not meaningful for the owned part. | The independent part may be shared or reassigned where the model allows it. |
Study the relationships separately before combining them
The QuizSession above contains both relationships, but a complete implementation of that exact shape would become a recipe for the first challenge. Instead, the code examples isolate the two ideas in different domains: a TrainingRun owns its RunLog, while an EquipmentCase groups independently existing Camera objects.
Java has no composition or aggregation keyword. Construction and references provide evidence, but the requirements about ownership and meaningful lifetime justify the relationship.
Python has no composition or aggregation keyword. Construction and references provide evidence, but the requirements about ownership and meaningful lifetime justify the relationship.
Map the reasoning back to the QuizSession model
| Step | What happens | Relationship evidence |
|---|---|---|
| 1 | Amina and Luis are created before the session. | Players have independent identities. |
| 2 | QuizSession receives those existing Player objects. | Aggregation evidence. |
| 3 | QuizSession creates an AnswerLog for itself. | Composition evidence. |
| 4 | The session delegates record work to its log. | The whole uses its component. |
| 5 | Amina can still be used independently. | Aggregated part retains identity. |
Modelled lifetime is not garbage-collection timing
At the design level, the session-owned AnswerLog has no meaningful role once its QuizSession is gone, while the independently created players can remain useful. That is enough to explain the relationship.
Likewise, storing a list of Player references does not copy the Player objects themselves. A shallow container copy still refers to the same independently existing Player objects.
The same real-world nouns can produce different relationships
Reusable dashboard system
Dashboard ◇— Widget. Widget objects come from a shared library, can exist before a dashboard and may appear on more than one dashboard. Aggregation is defensible.
One-off kiosk runtime
Dashboard ◆— Widget. The kiosk creates temporary Widget objects solely as parts of one dashboard instance, and those objects have no meaningful role outside it. Composition is defensible.
The nouns dashboard and widget do not determine the answer. Requirements determine ownership and lifetime. You will need to transfer that reasoning to a different pair of nouns in the challenge.
Can you justify the relationship?
Use ownership and independent lifetime, not just constructor syntax.
-
A QuizSession creates its own AnswerLog, and that log has no meaningful role outside that session in this model. Composition or aggregation?
Reveal model answer
Composition. QuizSession strongly owns the AnswerLog and the log's meaningful modelled lifetime is tied to the session.
-
A Player object exists in the roster before a QuizSession and can still be used afterward. Composition or aggregation?
Reveal model answer
Aggregation. The session uses an independently existing Player rather than owning the player's identity or lifetime.
-
Does seeing new AnswerLog() inside a constructor prove composition by itself?
Reveal model answer
No. Internal construction is useful evidence, but the decisive reasoning is the intended ownership and meaningful independent lifetime in the software model.
-
Where does the UML diamond go?
Reveal model answer
At the whole end of the relationship: filled for composition and hollow for aggregation.
-
If a composed part becomes unreachable when its whole is no longer used, must Java or Python reclaim its memory immediately?
Reveal model answer
No. Composition describes modelled ownership and lifetime, not a guaranteed garbage-collection time. Memory reclamation may occur later and reachability can depend on other references.
Explain, model and justify
B3.2.4 uses the command term Explain. You should be able to interpret code and UML, choose the correct whole–part relationship from requirements, draw the correct diamond at the whole end, complete a small model and justify the choice. You are not expected to architect a large object graph or manage garbage collection manually.
Challenges Choose one
Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.
Research Project Relationships
SelectedModel a ResearchProject that creates and owns one ProgressLog used only for that project, while using Researcher objects that already exist independently and may participate in other projects later. Draw a compact UML class diagram with the correct diamond at the whole end of each relationship, implement the small model, create the researchers before the project, and prove one researcher is still independently usable after the project has been used. Explain both relationship choices using ownership and meaningful independent lifetime rather than constructor syntax alone.
Same Nouns, Different Model
SelectedBuild two deliberately different team models. In a league database, Player objects exist independently of a LeagueTeam and can transfer between teams. In a one-off simulation, each SimulationTeam creates temporary SimPlayer objects that have no meaningful role outside that simulated team. Draw and implement both relationships, then explain why “Team has Players” is not enough information to classify the relationship. Include the correct UML diamonds and avoid claims about exact garbage-collection timing.
Selected challenge
This choice is shared with the portfolio setup page.
Plan your solution in handwritten pseudocode
Before opening your IDE or writing any program code, handwrite pseudocode for this challenge on paper.
Not marked complete. If you submit now, the GitHub README will record “No”.
Create your challenge folder
Run this command after planning. It creates the correct empty folder inside your portfolio.
Complete the challenge
Use your handwritten pseudocode as the starting plan, then write and test your solution in the folder created above.
Optional two-level scaffold
Try from your handwritten pseudocode first. Scaffold gives some structure; Scaffold + comments gives stronger guidance. Use only the level you need, and update your pseudocode first if the support changes your plan.
Submit for review
Run this when your program is complete. It creates the README, commits the folder and pushes it. The README records whether you marked the handwritten pseudocode as complete; the paper itself is handed to your teacher separately.