Composition vs Inheritance: Which Wins?

The deciding question is whether the relationship really is is-a. If a Car genuinely is a kind of Vehicle, inheritance models it well. If a Car merely has an Engine, composition is the honest model — and it is almost always the more flexible one.

Composition means holding a reference to the other object as a field and delegating to it. The class keeps its own identity and the collaborator's type can change at run time, which inheritance can never offer because a superclass is fixed at compile time.

public class Main {
    public static void main(String[] args) {
        // Composition: the vehicle HAS-A engine.
        Vehicle petrol = new Vehicle(new PetrolEngine());
        petrol.start();
        System.out.println("engine : " + petrol.getEngine().getClass().getSimpleName());

        // The same class, a different engine - impossible with inheritance.
        Vehicle electric = new Vehicle(new ElectricEngine());
        electric.start();
        System.out.println("engine : " + electric.getEngine().getClass().getSimpleName());
    }
}

class Engine {
    void start() {
        System.out.println("engine started");
    }
}

class PetrolEngine extends Engine {
    @Override
    void start() {
        System.out.println("petrol engine started");
    }
}

class ElectricEngine extends Engine {
    @Override
    void start() {
        System.out.println("electric engine started, silently");
    }
}

class Vehicle {
    private final Engine engine;

    Vehicle(Engine engine) {
        this.engine = engine;
    }

    void start() {
        engine.start();
    }

    Engine getEngine() {
        return engine;
    }
}

The output is the case for composition in one screen. The Vehicle class is identical in both cases; only the collaborator differs. With inheritance you would need a PetrolVehicle subclass and an ElectricVehicle subclass, and any existing code that held a Vehicle reference would be tied to one of them forever.

Composition also avoids the two classic inheritance problems. It does not create a false is-a relationship that lets a caller treat the composed object as the thing it merely contains. And it keeps the coupling explicit — the constructor says exactly what the class needs, so a test can supply a fake engine without any framework.

Each level of inheritance adds a level of indirection that a reader has to follow and a layer of coupling that a change can ripple through. A four-level hierarchy means that to understand what getPriority() returns on an UrgentNotification, you have to know whether the base class, the middle class or the leaf class implements it.

public class Main {
    public static void main(String[] args) {
        Notification n = new UrgentNotification();
        System.out.println("channel  : " + n.getChannel());
        System.out.println("priority : " + n.getPriority());
    }
}

class Notification {
    String getChannel() {
        return "email";
    }

    int getPriority() {
        return 1;
    }
}

class PriorityNotification extends Notification {
    @Override
    int getPriority() {
        return 5;
    }
}

class UrgentNotification extends PriorityNotification {
    @Override
    String getChannel() {
        return "sms";
    }
}

The output shows the two behaviours a reader has to trace. getChannel is overridden in the leaf class, so it returns sms. getPriority is not overridden in the leaf, so it resolves to the middle class and returns 5 — the value from two levels up.

The costs that matter in practice. A change to a base class method silently changes the behaviour of every descendant, including those written by teams who never read the base class. A subclass can also silently change the meaning of a method it did not intend to touch, which is the fragile base class problem. And the super chain makes it awkward to skip a level — there is no super.super, so a middle class that needs to reach past its parent has to be restructured.

Composition avoids most of this because nothing is inherited implicitly. What is the practical alternative to a hierarchy is a small set of collaborating objects, each with one job, wired together by a constructor. That is the direction most modern Java code moves in, and it pairs well with interfaces: program to the interface, compose the implementation.