Association, Aggregation, and Composition in Java

Inheritance describes an 'is-a' relationship between classes. But most real systems are built from a different kind of relationship altogether: objects that simply use, hold, or contain other objects. This chapter takes a deeper look at that family of relationships: association, aggregation, and composition.

What is Association?

Association is the broadest possible relationship between two classes: one class uses or interacts with another, without either owning the other. Both objects can exist completely independently, before, during, and after the interaction takes place.

class Doctor {

String name;

Doctor(String n) { name = n; }

void treat(Patient patient) {

System.out.println(name + " is treating " + patient.name);

}

}

class Patient {

String name;

Patient(String n) { name = n; }

}

Association can be one-directional, only Doctor knows about Patient, or bidirectional, where Patient also keeps a reference back to its Doctor. It can also be one-to-one, one-to-many, or many-to-many. None of these variations changes the core fact: neither object controls the other's lifecycle.

Aggregation: Has-A (Weak) Relationship

Aggregation is a special, stronger case of association: one class genuinely 'has' another as a meaningful part of itself, but the part's lifecycle remains independent of the whole. The contained object is typically created outside the containing class and simply passed in.

class Author {

String name;

Author(String n) { name = n; }

}

class Book {

String title;

Author author;   // Book HAS-A Author, but doesn't own its lifecycle

Book(String t, Author a) {

title = t;

author = a;

}

}

Author author = new Author("R.K. Narayan");

Book book = new Book("Malgudi Days", author);

// Discarding 'book' does not affect 'author '; it keeps existing independently

Composition: Has-A (Strong) Relationship

Composition tightens the relationship further: the contained object's lifecycle is entirely bound to its container. It is typically created inside the containing class's own constructor, never handed in from outside, and it has no independent reason to exist once the container is gone.

class Engine {

private final String type;

Engine(String t) { type = t; }

}

class Car {

private final Engine engine;   // created and owned entirely by Car

Car() {

engine = new Engine("V6");   // Car controls the Engine's entire lifecycle

}

}

Car car = new Car();

// There is no way to access or detach 'engine' from outside Car at all

Notice that engine is also declared private and final; this is typical of composition in well-written Java: the part is hidden from the outside world entirely, reinforcing that it has no existence or meaning independent of its owner.

Aggregation vs Composition with Examples

A simple way to tell the two apart in real code: ask whether the contained object could sensibly be reused somewhere else if you deleted the container. An Author can write for many books and outlive any one of them; that's aggregation. An Engine built specifically for one Car, with no plan to ever be reused elsewhere, is composition.

Quick Tip

UML diagrams represent these three relationships with different arrowheads: a plain line for association, a hollow diamond for aggregation, and a filled diamond for composition. You don't need to memorise UML notation to use these concepts well, but recognising the diamonds is useful if you ever read architecture diagrams at work.