Aggregation

Aggregation is a weak whole-part relationship between objects.

One object represents the whole and contains or manages other objects, but the contained objects can exist independently of it.

Aggregation means “has-a,” but without strong ownership of the object’s lifetime.

Simple Example

Consider a Team containing multiple Player objects.

class Player {
    private String name;

    Player(String name) {
        this.name = name;
    }
}

class Team {
    private List<Player> players;

    Team(List<Player> players) {
        this.players = players;
    }
}

The players are created outside the team and then passed to it.

If the Team object is deleted, the Player objects can continue to exist. They could join another team.

UML Notation

Aggregation uses a hollow diamond on the side of the whole:

Here:

• Team is the whole.
• Player is the part.
• The hollow diamond appears beside Team.

Multiplicity

Multiplicity shows how many parts can belong to the whole:

This means one team can contain zero or more players.

Main Characteristics

• It represents a whole-part relationship.
• The whole holds references to its parts.
• The parts can exist without the whole.
• The whole does not strongly control the parts’ lifetimes.
• A part may sometimes belong to more than one whole.
• UML represents it using a hollow diamond.
• It is stronger than a general association but weaker than composition.

More Examples

Possible examples of aggregation include:

• A department has employees.
• A team has players.
• A playlist has songs.
• A club has members.
• A library has books.

These examples assume the parts can continue to exist independently.

For example, deleting a playlist does not delete the songs themselves.

Aggregation vs Association

A general association means that two objects are connected:

Doctor - Patient

Aggregation adds a whole-part meaning:

Team <>- Player

Aggregation is a specialised form of association.

Aggregation vs Composition

The main difference is lifetime ownership.

Aggregation

The part can exist independently of the whole.

Team <>- Player

Deleting the team does not require deleting its players.

Composition

The part’s lifetime is strongly controlled by the whole.

House <#>- Room

In this model, a room is treated as an inseparable part of its house.

How to Recognise Aggregation

Ask these questions:

1. Is one object logically a whole containing other objects?
2. Can each part exist without that whole?
3. Can the part be transferred to another whole?
4. Does deleting the whole leave the part valid?

If the answers are mostly yes, aggregation may be appropriate.

For example, a player can:

• Exist before joining a team
• Leave the team
• Join another team
• Exist after the team is removed

This suggests aggregation rather than composition.

When to Use Aggregation

Use aggregation when:

• The relationship has clear whole-part meaning.
• The parts have independent lifetimes.
• The whole receives existing objects rather than creating them exclusively.
• Parts can be moved between different containers.
• The whole groups or manages parts without owning their existence.

Implementation Note

Most programming languages do not have a special aggregation keyword.

Aggregation is expressed using normal object references:

class Department {
    private List<Employee> employees;

    Department(List<Employee> employees) {
        this.employees = employees;
    }
}

Its meaning comes from the design:

• Employees are created independently.
• The department receives their references.
• Removing the department does not destroy the employees.

The same code structure could represent association or composition. The intended ownership and lifecycle rules determine the actual relationship.

Common Mistakes

Treating every collection as aggregation

A class containing a list does not automatically create aggregation. There must be a meaningful whole-part relationship.

Confusing storage with ownership

Holding a reference to an object does not necessarily mean owning its lifetime.

Using aggregation when the part cannot exist independently

If the part is created and destroyed with the whole, composition is usually more accurate.

Relying only on code syntax

Aggregation is primarily a design concept. Its meaning may not be obvious from fields and constructors alone.

Overusing the UML aggregation symbol

In practice, teams sometimes use plain association unless the weak whole-part meaning provides important information.

Interview Explanation

A short answer:

Aggregation is a weak whole-part relationship in which the whole contains references to parts, but the parts can exist independently of the whole. UML represents it with a hollow diamond.

A stronger answer:

Aggregation is a specialised association that represents weak ownership. For example, a team aggregates players because players can exist before joining the team, leave it and continue existing after the team is removed. This differs from composition, where the whole strongly controls the parts’ lifetimes.

Interview Questions

1. What is aggregation in object-oriented design?
2. Why is aggregation called a weak ownership relationship?
3. Can an aggregated object exist independently?
4. What UML symbol represents aggregation?
5. Where is the hollow diamond placed?
6. How does aggregation differ from association?
7. How does aggregation differ from composition?
8. Does a programming language enforce aggregation?
9. Can an aggregated object be shared between multiple objects?
10. Is every object collection an aggregation?

Key Takeaways

• Aggregation represents a weak whole-part relationship.
• The parts can exist independently of the whole.
• The whole does not strongly control the parts’ lifetimes.
• UML uses a hollow diamond beside the whole.
• Aggregation is more specific than association.
• It is weaker than composition.
• Normal object references implement it in code.
• Ownership and lifecycle rules determine whether a relationship is aggregation.