has-a vs is-a Relationships

An is-a relationship is a type relationship. It says that one thing can be used wherever the other is expected, which is exactly the substitutability guarantee that inheritance provides. A has-a relationship is a possession relationship. It says that one object holds another and delegates work to it, which is composition.

public class Main {
    public static void main(String[] args) {
        Car car = new Car(new Engine("v8"));
        car.start();
        System.out.println(car.engine().type());
    }
}

class Engine {
    private final String type;
    Engine(String type) { this.type = type; }
    void start() { System.out.println("engine running"); }
    String type() { return type; }
}

class Car {
    private final Engine engine;
    Car(Engine engine) { this.engine = engine; }
    void start() { engine.start(); }
    Engine engine() { return engine; }
}

The car is the clear has-a case. It holds an engine, the engine has its own lifecycle, and the car delegates starting to it. A car is not an engine, and a code path that accepts a car cannot accept an engine. Nothing about the car's type hierarchy promises it behaves like an engine.

The test for is-a is substitutability, and it is a strong test. Ask whether the child could replace the parent everywhere the parent is used, without any code breaking. If yes, you have an is-a and inheritance is appropriate. If the answer is no, or if it needs a cast or a type check, then it is not really an is-a.

The trap to warn about is a hierarchy built on the word is loosely. A manager is-a employee in one direction and an employee is-a person, but a manager is not always interchangeable with every employee. When the substitutability test fails, model the relationship with a has-a instead, and let the objects collaborate.

Because has-a is more flexible and less coupled. With composition, the collaborator is chosen at construction time and can even be swapped at run time, and the two classes stay independent so each can be tested and reused on its own. With inheritance, the relationship is fixed in the type system and lasts for the life of the hierarchy.

Inheritance also carries obligations. A subclass must honour the parent's contract, the parent can never be changed without checking every descendant, and a hierarchy that keeps growing becomes expensive to modify. Composition avoids all of that, and it allows behaviour to be recombined in ways a hierarchy cannot express, such as wrapping one implementation in a decorator.

That said, is-a is the right answer when the relationship is genuinely a kind of relationship and the substitutability test passes. A cat really is an animal, and code that accepts an animal should work correctly with a cat. A savings account really is an account. Those are stable concepts where the hierarchy captures something real about the domain.

The practical heuristic is to ask what happens if the relationship changes. If the two things will always be one of each other, model it as a has-a with a constructor and a small interface. If one genuinely is a kind of the other and that will not change, inheritance is a good fit and communicates that to readers.