Association, aggregation and composition

Interviewers ask this in two places. In a core Java round, it's a quick check that you can define the terms precisely and say what decides which one you have (hint: lifecycle and ownership, not the syntax). In a low-level design round, it's everywhere: the moment you draw a class diagram for a parking lot or a food-delivery app, the interviewer reads your arrows and diamonds and asks "who owns this?" and "what happens to these when that's deleted?".

For this lesson, we'll focus on what each relationship means in UML and in plain English, how each one looks in Java code, directionality and multiplicity, how Java's garbage collector sees (and doesn't see) ownership, and how to use all of this in an LLD interview.

01Picture it first: a house, a football club and a clinic

A house and its rooms is composition. The rooms are built as part of the house, belong to exactly one house, and when the house is demolished, the rooms go with it. A football club and its players is aggregation. The club groups them, but players existed before they signed and will play for another club after. A doctor and a patient is plain association. They meet, they know each other, neither owns the other, and either can exist without the other.

UML gives each one its own line ending, and the diagram below is the notation you'll draw in an interview.

Fig. 1

UML notation for three relationships: Doctor to Patient as a plain association line with many-to-many multiplicity, Team to Player with a hollow diamond at Team for aggregation, and Order to OrderLine with a filled diamond at Order for composition, each with a short meaning on the right

Notice three things:

• The diamond sits at the whole, never at the part. Hollow means shared, filled means owned.
• Multiplicity goes at each end: 1 order has 1..* lines; each line belongs to exactly 1 order. A composed part can belong to at most one whole at a time.
• An arrowhead on the line marks navigability: which side can reach the other in code. No arrowheads usually means "not specified" or bidirectional.

There's also a weaker cousin you'll sometimes draw: dependency, a dashed arrow, for "uses temporarily", such as a method parameter (checkout.pay(gateway)) that's never stored in a field.

02Under the hood: what each one looks like in Java

Java has no owns or shares keyword. In all three cases, you write a field that holds a reference. The relationship lives in how you create, expose and release that reference. Let's write each one properly.

The diagram below separates the three relationships by the two questions that matter most in code: sharing and lifecycle.

Fig. 2

A lifecycle map contrasts association as independent uses links, aggregation as a shared whole-part link with a hollow diamond, and composition as exclusive owned parts with a filled diamond and delete cascade

Composition: Order owns its OrderLines

public final class Order {
    private final String id;
    private final List<OrderLine> lines = new ArrayList<>();

    public Order(String id) { this.id = id; }

    public void addLine(String sku, int quantity, BigDecimal unitPrice) {
        lines.add(new OrderLine(sku, quantity, unitPrice));   // the whole creates its parts
    }

    public List<OrderLine> lines() { return Collections.unmodifiableList(lines); }

    public BigDecimal total() {
        return lines.stream().map(OrderLine::subtotal).reduce(BigDecimal.ZERO, BigDecimal::add);
    }

    public record OrderLine(String sku, int quantity, BigDecimal unitPrice) {
        public OrderLine {
            if (quantity <= 0) throw new IllegalArgumentException("quantity must be positive");
        }
        BigDecimal subtotal() { return unitPrice.multiply(BigDecimal.valueOf(quantity)); }
    }
}

var order = new Order("ORD-1001");
order.addLine("SKU-1", 2, new BigDecimal("499.00"));
order.addLine("SKU-7", 1, new BigDecimal("1299.00"));
System.out.println(order.total());   // prints: 2297.00
order.lines().clear();               // throws UnsupportedOperationException

Notice how ownership is enforced:

• The whole creates the parts. Callers pass data (sku, quantity, price), not OrderLine objects they might keep and mutate.
• Nothing mutable escapes. The list is exposed read-only, and OrderLine is an immutable record, so handing out a line is harmless.
• The part makes no sense alone. OrderLine is nested inside Order, so even its name says "this belongs to an order".

Aggregation: Team groups Players

final class Player {
    private final String name;
    Player(String name) { this.name = name; }
    @Override public String toString() { return name; }
}

final class Team {
    private final String name;
    private final Set<Player> squad = new LinkedHashSet<>();
    Team(String name) { this.name = name; }

    void sign(Player p)    { squad.add(p); }       // part created elsewhere, passed in
    void release(Player p) { squad.remove(p); }    // removing does not destroy the player
    Set<Player> squad()    { return Set.copyOf(squad); }
}

Player virat = new Player("Virat");
Team rcb = new Team("RCB");
Team india = new Team("India");
rcb.sign(virat);
india.sign(virat);                       // the same Player object in two teams
rcb = null;                              // the team is gone...
System.out.println(india.squad());       // prints: [Virat]  ...the player isn't

The structural difference from Order is small but decisive: the part is created outside and passed in, it can sit in more than one whole, and the whole's API talks about signing and releasing, never deleting.

Association: Doctor and Patient

Association has no whole and no part. A doctor treats many patients and a patient sees many doctors (many-to-many). If both sides need to navigate to the other, the association is bidirectional, and you must keep both sides in sync: