Aggregation vs Composition: Association Deep Dive
The difference between weak and strong associations in UML. When to use aggregation vs composition for independent vs dependent entities.
A class diagram is more than just a list of classes; it is a map of relationships. While inheritance (ISA) is straightforward, association (HAS-A) has two flavors that often trip people up in interviews. Understanding the difference between Aggregation and Composition is key to designing robust systems.
The Essentials
- Two relationship categories: Inheritance (ISA) and Association (HAS-A). Every class relationship falls into one of these.
- Aggregation (Weak): If class B can exist without class A, then A aggregates B. Represented by an empty diamond.
- Composition (Strong): If class B cannot meaningfully exist without class A, then A composes B. Represented by a filled diamond.
- The Deletion Test: If deleting the parent should delete the child, it is composition. If the child survives, it is aggregation.
- Favor Association over Inheritance: Association is flexible and avoids the "class explosion" problem.
Aggregation: The "Collecting" Relationship
Aggregation comes from "aggregate" -- to collect or assemble. When you aggregate something, you are collecting objects that already existed. They would still exist if you were not there.
The test is simple: can the child object exist independently of the parent? If yes, it is aggregation.
Consider a Playlist and its Tracks. A track exists in the library before any playlist is created. If you delete a playlist, the tracks still exist in the database. The playlist just aggregates existing tracks.
class Playlist {
private name: string;
private tracks: Track[]; // Aggregation: Track exists independently
}In a class diagram, aggregation is represented by an empty (hollow) diamond on the side of the owner class.
Composition: The "Creating" Relationship
Composition comes from "compose" -- to create or make. A composer makes something that would not have existed without them.
The test is the mirror of aggregation: can the child object exist meaningfully without the parent? If no, it is composition.
Consider a Board and its Cells. A cell in row 0, column 0 of a 3x3 TicTacToe board has no meaning outside of that board. If you destroy the board, the cells lose all purpose and should be destroyed with it. The board composed the cells.
class Board {
private size: number;
private cells: Cell[][]; // Composition: Cell has no meaning without Board
}In a class diagram, composition is represented by a filled (solid) diamond on the side of the owner class.
The owned object has an independent existence. It can survive without the owner.
Movie → Actor
Team → Player
The owned object has no meaningful existence without the owner. It was created by the owner.
Order → OrderItem
Invoice → LineItem
Why the Distinction Matters
In terms of raw code, both aggregation and composition look identical: one class has a field of another class type. However, the distinction informs two critical design decisions:
- Deletion Semantics: When you delete a
Showing, itsSeatsshould be deleted too (composition). When you delete aPlaylist, theTracksshould not be deleted (aggregation). - Schema Nullability: In a composition relationship, the foreign key should never be null -- the child always has a parent. In aggregation, nulls are possible.
One Rule Worth Remembering
When you have a choice between inheritance and association, prefer association. Inheritance is rigid and leads to "class explosion" when you have multiple axes of variation. Association is flexible; you can swap out associated objects at runtime.
With our understanding of relationships clear, we are ready to build the complete TicTacToe class diagram.
Further Reading and Watching
Practice what you just read.
Keep reading