Composition vs Inheritance — has-a vs is-a

Direct Answer

Inheritance defines a subtype with extends; the child receives inherited accessible behavior and must satisfy the parent contract. Composition builds an object from collaborators held in fields and delegates work to them. Neither choice automatically creates tight or loose coupling, and composition is replaceable at runtime only when the design exposes that option.

Code Example

interface Engine {
    void start();
}

final class PetrolEngine implements Engine {
    public void start() { System.out.println("petrol"); }
}

final class Car {
    private final Engine engine;

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

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

Car car = new Car(new PetrolEngine());

Car uses composition and its engine is fixed after construction. A different Car can receive another Engine; this object does not magically swap collaborators at runtime.

Common Mistakes & Pitfalls

• Saying a subclass inherits everything: constructors are not inherited, and private members are not directly accessible.
• Calling every field loose coupling: a field typed as a large concrete class can still bind the owner closely to it.
• Promising runtime swapping: many composed dependencies are fixed after construction.
• Using inheritance only to borrow methods: delegation usually avoids a false subtype.
• Using a real-world noun test alone: behavioral substitutability matters more than whether the sentence 'X is a Y' sounds natural.