Aggregation

A whole that groups parts it does not own: the parts are created elsewhere, can be shared, and outlive the whole.

Overview

Aggregation is a whole-part relationship in which the whole does not own its parts. A team has players, a department has employees, a playlist has songs. The whole groups the parts and uses them, but it did not create them, it does not decide when they end, and it may share them with other wholes. When the team is disbanded, the players are still there.

That last sentence is the whole idea. Every other relationship question in a low level design interview comes back to one test: what happens to the part when the whole goes away? If the part survives, you have aggregation (or a plain association). If the part goes with it, you have composition.

Whole, part, and who owns whom

Object-oriented design names three kinds of link between classes. They differ in how tightly the lifecycles are tied.

Association — Do these objects know about each other? — Yes — Yes — plain line
Aggregation — Does this whole group these parts? — Yes — Yes — hollow diamond at the whole
Composition — Does this whole own these parts? — No — No — filled diamond at the whole

What the UML standard says

The UML 2.5.1 specification defines aggregation as a property of an association end, with three values. Knowing the exact wording helps, because interviewers often ask for the difference and accept only a precise answer.

none — no aggregation semantics — an ordinary association
shared — the precise semantics vary by application area and modeler — the hollow diamond; the parts are grouped but not owned
composite — the composite is responsible for the existence and storage of the parts; a part is in at most one composite at a time; deleting the composite deletes its parts — the filled diamond; real ownership

Two things follow from that table. First, the standard leaves shared aggregation loose on purpose, so when you draw a hollow diamond you should say what you mean by it: 'the department lists its employees but does not own them.' Second, only composition carries a lifecycle rule. Aggregation is a statement about grouping, not about memory or deletion.

How it looks in code

In code, aggregation means the whole receives parts that already exist. They arrive through the constructor, a setter or an add method. The whole keeps references but never calls the part's constructor itself. Because the caller still holds the parts, they live on after the whole is gone, and the same part can be handed to a second whole.

Aggregation in a database

The same idea appears in a schema. A part that may exist without its whole gets a nullable foreign key, and deleting the whole either detaches the parts (ON DELETE SET NULL) or is refused while parts still point at it (RESTRICT). PostgreSQL's documentation suggests CASCADE for the case where the referencing row is a component that cannot exist independently, and RESTRICT or NO ACTION when the two tables are independent objects. The first case is composition, not aggregation.

Alice — NULL
Bob — NULL

The players survive the delete with their team cleared. That is the database form of 'the part outlives the whole'.

What you will be able to do

Say in one sentence how aggregation differs from composition and from a plain association.
Draw it correctly in UML: hollow diamond at the whole, multiplicity at both ends.
Implement it in code by passing existing objects in, never constructing them inside the whole.
Map it to a schema with a nullable foreign key and the right delete rule.
Defend the choice in an interview with the lifecycle test.

Interview questions

How is aggregation different from composition?
How do you implement aggregation in code, and what does getting it wrong look like?
When is aggregation the right call, and when is a plain association enough?
Can one part belong to several wholes at the same time?
How does aggregation map to a database schema?