Aggregation
Aggregation models a whole containing parts that can outlive or be shared beyond that whole. The hollow diamond describes a domain ownership decision, not a garbage-collector instruction.
What you’ll understand
- Aggregation models a whole containing parts that can outlive or be shared beyond that whole. The hollow diamond describes a domain ownership decision, not a garbage-collector instruction.
- Team stores member references and clears only its own collection when dissolved.
- Evaluate the tradeoff: Aggregation is often expressible as an ordinary association. Use it to clarify independent lifetimes, not to invent automatic deletion semantics.
Useful first: Classes and Objects
The idea and when to recognize it
Aggregation models a whole containing parts that can outlive or be shared beyond that whole. The hollow diamond describes a domain ownership decision, not a garbage-collector instruction.
- Requirement: A team groups employees, but dissolving the team must not deactivate those employees.
- Change to anticipate: Clear team membership while preserving the external employee records.
- Design goal: Team stores member references and clears only its own collection when dissolved.
Start with the concrete problem
A team groups employees, but dissolving the team must not deactivate those employees.
Clear team membership while preserving the external employee records.
| Direct implementation | Revised design |
|---|---|
| Deactivating every member when a team dissolves confuses grouping with ownership. | Team stores member references and clears only its own collection when dissolved. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Aggregation is often expressible as an ordinary association. Use it to clarify independent lifetimes, not to invent automatic deletion semantics. |
Responsibilities and contracts
Team stores member references and clears only its own collection when dissolved.
- Team: Groups independently owned employees. Public operations: dissolve()
- Employee: Exists outside the team. Public operations: active
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A playlist groups songs that remain in the music library when the playlist is deleted.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Aggregation is often expressible as an ordinary association. Use it to clarify independent lifetimes, not to invent automatic deletion semantics.
Common mistake: Deactivating every member when a team dissolves confuses grouping with ownership.
- Explain the choice: Team stores member references and clears only its own collection when dissolved.
- Challenge your choice: Aggregation is often expressible as an ordinary association. Use it to clarify independent lifetimes, not to invent automatic deletion semantics.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…