Inheritance in Java

Inheritance is the mechanism that lets you build class hierarchies where subclasses automatically receive fields and methods from their ancestors — code reuse through a “is-a” relationship.

Introduction

Inheritance is the mechanism that lets subclasses automatically receive the fields and methods of their parent classes — code reuse through an “is-a” relationship. A Dog is an Animal, so Dog inherits from Animal and automatically gets name, age, eat(), and sleep() without reimplementing them. The extends keyword establishes this relationship, and Java enforces that any subclass constructor must call super() to ensure the parent is initialized before the child adds its own state.

The power of inheritance is also its trap. Inheritance creates tight coupling — the subclass is bound to the parent’s implementation details, not just its public contract. A parent that changes internally can silently break a subclass that depended on those internals. The Liskov Substitution Principle states that a subclass must work everywhere its parent works, but violating this is easier than it sounds: a Square that extends Rectangle and independently enforces equal width and height cannot be substituted for a Rectangle in code that sets width and height independently. This is the fragile base class problem.

This post covers when inheritance genuinely fits (true “is-a” with shared identity), when composition is the better tool (“has-a” relationships), the mechanics of super() calls and method overriding, and the design rules that keep inheritance hierarchies from becoming liability.

When to Use

Use inheritance when:

• A true “is-a” relationship exists — a Dog is an Animal
• Shared behavior is identical — subclasses should use the exact same implementation
• You need polymorphism — treating different types through a common supertype
• Designing for extension — allowing subclasses to customize behavior via overriding

// Parent class
public class Animal {
    protected String name;
    protected int age;

    public Animal(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void eat() {
        System.out.println(name + " is eating");
    }

    public void sleep() {
        System.out.println(name + " is sleeping");
    }
}

// Child class
public class Dog extends Animal {
    private String breed;

    public Dog(String name, int age, String breed) {
        super(name, age);  // Call parent constructor
        this.breed = breed;
    }

    @Override
    public void eat() {
        System.out.println(name + " (a " + breed + ") is eating kibble");
    }

    public void bark() {
        System.out.println(name + " says Woof!");
    }
}

When Not to Use

Avoid inheritance when:

• “Has-a” relationship — a Car has an Engine, not is an Engine
• Different implementations for same behavior — use interfaces instead
• Unrelated classes — don’t force hierarchy where none exists
• Multiple inheritance needed — Java only supports single class inheritance, use interfaces

// Bad: forced inheritance
public class Stack extends ArrayList {  // Stack is not an ArrayList!
    // Inappropriate — ArrayList has too much functionality
}

// Good: composition
public class Stack {
    private List<String> items = new ArrayList<>();  // Has-a relationship
}

Inheritance Hierarchy — Mermaid Diagram

classDiagram
    class Animal {
        +String name
        +eat() void
        +sleep() void
    }
    class Dog {
        +String breed
        +bark() void
        +eat() void
    }
    class Cat {
        +boolean indoor
        +meow() void
        +eat() void
    }
    class Bird {
        +boolean canFly
        +chirp() void
    }
    Animal <|-- Dog
    Animal <|-- Cat
    Animal <|-- Bird
    note for Dog "extends — inherits name, age,\neat(), sleep() from Animal"

Failure Scenarios

1. Breaking the Liskov Substitution Principle

public class Rectangle {
    protected double width;
    protected double height;

    public void setWidth(double w) { width = w; }
    public void setHeight(double h) { height = h; }
}

public class Square extends Rectangle {
    // Violation: a Square cannot independently set width and height
    @Override
    public void setWidth(double w) {
        width = w;
        height = w;  // Must keep them equal
    }

    @Override
    public void setHeight(double h) {
        width = h;
        height = h;
    }
}

// If code expects Rectangle, Square breaks it:
Rectangle r = new Square();
r.setWidth(5);
r.setHeight(3);  // Not a square anymore! But stored width is now 3 too

2. Forgetting to Call super()

public class Parent {
    public Parent(String name) {
        System.out.println("Parent constructed: " + name);
    }
}

public class Child extends Parent {
    public Child() {
        // super(); // IMPLICIT — but only if Parent has no-arg constructor
        // If Parent has only Parent(String), this won't compile
    }
}

3. Overriding Non-Virtual Methods

public class Base {
    public void finalMethod() {  // Cannot override
        System.out.println("Base behavior");
    }
}

Trade-off Table

Code Snippets

Method Overriding with @Override

public class Vehicle {
    protected double speed;

    public void move() {
        System.out.println("Vehicle moving at " + speed + " km/h");
    }

    public double getSpeed() {
        return speed;
    }
}

public class Car extends Vehicle {
    private int wheels = 4;

    @Override  // Compiler checks this is actually overriding something
    public void move() {
        System.out.println("Car driving at " + speed + " km/h with " + wheels + " wheels");
    }

    public void honk() {
        System.out.println("Car honking!");
    }
}

Using super to Access Parent Members

public class Employee {
    protected String name;
    protected double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public void work() {
        System.out.println(name + " is working");
    }

    public String getInfo() {
        return name + " earns " + salary;
    }
}

public class Manager extends Employee {
    private int teamSize;

    public Manager(String name, double salary, int teamSize) {
        super(name, salary);  // Call parent constructor
        this.teamSize = teamSize;
    }

    @Override
    public void work() {
        super.work();  // Call parent's work() first
        System.out.println(name + " is also managing " + teamSize + " people");
    }

    @Override
    public String getInfo() {
        return super.getInfo() + " (manages " + teamSize + ")";  // Extend parent info
    }
}

Observability Checklist

• Inheritance only for true “is-a” relationships
• @Override annotation used on all overriding methods
• super() called explicitly when parent has no default constructor
• Parent methods accessible via super when needed
• Liskov Substitution Principle respected — subclasses work wherever parents are expected

Security Notes

• Don’t expose internal state via protected fields — use protected methods
• Validate in subclass — don’t trust parent invariants alone
• Immutable parent — if parent is immutable, subclass should be too
• Constructor security — don’t let subclass constructors bypass parent initialization

public class SecureAccount {
    private final String accountId;
    private double balance;

    // Constructor sets required invariants
    public SecureAccount(String accountId, double initialBalance) {
        if (accountId == null || accountId.isEmpty()) {
            throw new IllegalArgumentException("Invalid account ID");
        }
        this.accountId = accountId;
        this.balance = initialBalance >= 0 ? initialBalance : 0;
    }
}

// Subclass must call super(), which validates accountId
public class SavingsAccount extends SecureAccount {
    private double interestRate;

    public SavingsAccount(String accountId, double initialBalance, double interestRate) {
        super(accountId, initialBalance);  // Parent validation runs first
        this.interestRate = interestRate;
    }
}

Pitfalls

1. Deep inheritance hierarchies — prefer shallow hierarchies (max 2-3 levels)
2. Forcing inheritance where composition fits better — “has-a” vs “is-a”
3. Breaking substitutability — subclass must work wherever parent is expected
4. Overriding methods that weren’t designed for extension — the fragile base class problem
5. Diamond inheritance — not possible in Java (use interfaces for multiple contracts)

// Common mistake: inheritance for code reuse rather than polymorphism
class MyStack extends ArrayList {  // Wrong — Stack is not an ArrayList
    public void push(Object item) { add(item); }
    public Object pop() { return remove(size() - 1); }
}

// Correct: composition
class MyStack {
    private List<Object> items = new ArrayList<>();
    public void push(Object item) { items.add(item); }
    public Object pop() { return items.remove(items.size() - 1); }
}

Quick Recap

• extends = inheritance keyword for classes (single inheritance only)
• super = reference to parent class members (constructor call super(), method call super.method())
• @Override = annotation ensuring method actually overrides parent method
• Subclass must call super() explicitly if parent has no default constructor
• Liskov Substitution Principle = subclass objects must be usable wherever parent objects are expected
• Favor composition over inheritance = “has-a” over “is-a” for flexibility

Interview Questions

Further Reading

• Polymorphism in Java — runtime method dispatch
• Composition over Inheritance — alternative to inheritance
• The Object Class in Java — root of all class hierarchies

Conclusion

Inheritance models “is-a” relationships — a Dog is an Animal, so Dog can inherit from Animal. The child class automatically receives the parent’s fields and methods, gaining reusable behavior without manual implementation. The extends keyword establishes this relationship, and super() calls ensure parent initialization runs before child-specific setup.

The inheritance hierarchy diagram shows how subclasses form a tree rooted at a common ancestor. At the top of every Java class hierarchy sits Object, which provides fundamental methods like toString(), equals(), and hashCode() (detailed in The Object Class in Java). Understanding this chain helps explain why all objects share certain behaviors.

Method overriding lets subclasses replace parent implementations with their own. The @Override annotation is not optional — it is the compiler’s sanity check that you are actually overriding something, catching typos in method names before they become runtime surprises. The @Override annotation combined with the Liskov Substitution Principle ensures subclasses honor their parent’s contract: anywhere an Animal is expected, a Dog must work.

The trade-off table reveals why composition (detailed in Composition over Inheritance) is often preferred. Inheritance creates tight coupling — the subclass is bound to the parent’s implementation details, which can change unexpectedly. When inheritance truly models an “is-a” relationship with a stable parent class, it is appropriate; but for flexible designs that need runtime behavior swapping, composition is the better tool.

Inheritance interacts with polymorphism (explored in Polymorphism in Java) — subclass instances can be stored in parent-type variables, and the correct method gets called based on the actual object type at runtime, not the reference type. This is the mechanism that makes interfaces and inheritance hierarchies powerful for writing flexible, extensible code.