Association vs Aggregation vs Composition

The three words all mean one class refers to another, and they differ in how strong that reference is. Association is the general term: a teacher is associated with a school, and either may exist alone. Aggregation is association where the parts can exist independently of the whole, so a department holds employees but does not own their lifetimes. Composition is the strong case, where the parts cannot exist without the whole and are created and destroyed with it.

public class Main {
    public static void main(String[] args) {
        Department eng = new Department("Engineering");
        eng.add(new Employee("Ada"));
        eng.add(new Employee("Grace"));
        System.out.println(eng.size());
        eng.printAll();
    }
}

class Department {
    private final String name;
    private final java.util.List<Employee> members = new java.util.ArrayList<>();
    Department(String name) { this.name = name; }
    void add(Employee e) { members.add(e); }
    int size() { return members.size(); }
    void printAll() {
        for (Employee e : members) {
            System.out.println(name + ": " + e);
        }
    }
}

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

The example shows aggregation. The department holds a list of employees, but the employees are constructed outside and passed in, so they exist independently and could be in two departments, in a reporting structure, or on their own. The department provides the grouping and the operations over the group, but it does not control the lifetime of its parts.

That is the practical difference to emphasise in an interview. Aggregation is modelled with a collection and an add method, and the parts are created by the caller. Composition is modelled the same way in code, but the whole creates the parts internally and there is no API for adding one from outside, so the one-to-many relationship cannot be broken.

In a class diagram, aggregation is drawn as a hollow diamond and composition as a filled one, but the language enforces nothing here. The diamond is documentation of an intention, and the intention has to be kept by the design: if you claim composition, the part must not be reachable from anywhere except the whole.

Association simply means two things are connected. A customer places an order, a student attends a course. The connection may be temporary, may be many-to-many, and neither side has to be built for the other.

Aggregation is a whole made of parts that have their own life. A playlist of songs, a folder of files, a team of people. You can take a song out of the playlist and it still exists. The whole knows the parts, but the parts do not depend on the whole.

Composition is a whole that owns its parts. A house owns its rooms, in the sense that a room cannot meaningfully exist without the house. The whole creates the parts, and when the whole is gone the parts are gone with it. There is no way to hand a room to somebody else and keep it alive.

The test that separates aggregation from composition is lifetime. Ask whether the part can outlive the whole. If it can, you have aggregation. If it cannot, you have composition, and the code should make that impossible rather than merely documented.

Start from the domain, not from the diagram. Ask what the business means. If an invoice can exist without the order that produced it, if a cart line has a meaning on its own, or if an employee belongs to several departments over time, the relationship is aggregation. If the line has no meaning outside the invoice, or if the room cannot exist without the building, it is composition.

Then check the lifetime against the code you are about to write. Composition means the whole creates the parts, keeps them to itself, and there is no public way to attach an existing part from outside. Aggregation means the parts are constructed by someone else and handed over, and the whole keeps a collection it does not own.

The failure mode to avoid is declaring composition in the diagram and implementing aggregation in the code, because a caller can then remove a part that the whole still needs. The diagram becomes a lie and the next developer trusts it. If you claim composition, expose no add or remove operation that accepts an externally created part.

There is a useful practical consequence of composition: because the whole controls the parts, it can guarantee invariants across them. A composed invoice can be certain that its total matches its lines, because it is the only thing that creates the lines. With aggregation that guarantee is much harder, because the parts came from outside.

The last point to make in an interview is that the distinction is a design commitment, not a labelling exercise. You are choosing who is allowed to create the parts and who is allowed to destroy them, and the code should make that choice visible.