Java Inheritance: extends, super, and Overriding

Inheritance Is "Is-A" Reuse

Inheritance lets a new class build on an existing one. The new class - the subclass - automatically gets the fields and methods of the superclass, then adds or changes whatever it needs. You reach for it when one type is a more specific kind of another: a Dog is an Animal, a SavingsAccount is a BankAccount.

You write it with the extends keyword. Everything public or protected in the parent is available in the child without rewriting it.

class Animal {
    String name;

    Animal(String name) { this.name = name; }

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

class Dog extends Animal {
    Dog(String name) { super(name); }   // pass name up to Animal

    void bark() { System.out.println(name + " says woof"); }
}

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog("Rex");
        d.eat();    // inherited from Animal
        d.bark();   // defined on Dog
    }
}

Dog never declares name or eat(), yet it has both. That is the whole point: shared behavior lives in one place.

super: Reaching the Parent

A subclass constructor must make sure the parent is set up first. You do that with super(...), which calls the parent's constructor and must be the first statement in the subclass constructor. If you leave it out, Java inserts a silent call to the parent's no-argument constructor - and if the parent has no such constructor, the code won't compile.

class Account {
    double balance;

    Account(double opening) {
        balance = opening;
        System.out.println("Account opened with " + opening);
    }
}

class SavingsAccount extends Account {
    double rate;

    SavingsAccount(double opening, double rate) {
        super(opening);     // run Account's constructor first
        this.rate = rate;
        System.out.println("Savings rate set to " + rate);
    }
}

public class Main {
    public static void main(String[] args) {
        new SavingsAccount(100.0, 0.05);
    }
}

The output shows the parent constructor runs before the child's body - construction flows from the top of the hierarchy down.

Overriding Methods

A subclass can replace an inherited method by redefining it with the same signature. This is overriding, and you should always tag it with @Override. The annotation isn't required, but it makes the compiler verify you actually matched a parent method - it catches typos like tostring() instead of toString() that would otherwise silently create a brand-new method.

class Animal {
    String speak() { return "..."; }
}

class Cat extends Animal {
    @Override
    String speak() { return "meow"; }
}

class Cow extends Animal {
    @Override
    String speak() { return "moo"; }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Cat(), new Cow(), new Animal() };
        for (Animal a : animals) {
            System.out.println(a.speak());   // each runs its own version
        }
    }
}

Even though the array is typed Animal, each element runs its own speak(). Java picks the method based on the real object at runtime, not the variable's declared type - that's the foundation of polymorphism.

Calling the Parent's Version with super.method()

Overriding doesn't have to throw away the parent's work. Use super.method() to run the inherited version and then add to it:

class Logger {
    void log(String msg) { System.out.println("[log] " + msg); }
}

class TimestampLogger extends Logger {
    @Override
    void log(String msg) {
        super.log("at t=0 " + msg);   // reuse the parent, then extend
    }
}

public class Main {
    public static void main(String[] args) {
        new TimestampLogger().log("server started");
    }
}

Without super., calling log inside TimestampLogger.log would call itself and recurse forever. super. explicitly means "the parent's version."

Inherited Fields and Access

A subclass sees the parent's public and protected members but not its private ones. private fields still exist in the object - the parent's own methods can touch them - but the subclass cannot reference them directly. Use protected, one of Java's access modifiers, when you want subclasses to have access while keeping a member hidden from unrelated code.

class Base {
    private int secret;      // invisible to subclasses
    protected int shared;    // visible to subclasses
}

class Derived extends Base {
    void demo() {
        shared = 5;          // OK
        // secret = 5;       // compile error - private to Base
    }
}

This is also why a subclass constructor often must call super(...): it's the only way to initialize the parent's private state.

Stopping Inheritance with final

Sometimes a class should not be extended at all - String is final for exactly this reason. Marking a class final forbids subclassing; marking a method final forbids overriding it while still allowing the class to be extended.

final class Constants { }            // cannot be subclassed

class Config {
    final void load() { }            // subclasses may extend Config
                                     // but cannot override load()
}

Reach for final when a class's behavior must be guaranteed and immutable across the program - it's a deliberate "do not extend" signal, not the default.

A Common Gotcha: Favor Composition When It's Not "Is-A"

Inheritance is tempting because it reuses code, but it tightly couples the child to the parent. If the relationship isn't a genuine "is-a" - say a Car that happens to need an Engine - don't make Car extends Engine. A car has an engine, it isn't one. Model that with a field (composition) instead:

class Car {
    private Engine engine = new Engine();   // Car HAS-A Engine

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

Use inheritance only when the subclass truly is a specialized form of the superclass and you want to inherit and substitute its behavior.

Next: Interfaces

Inheritance with extends gives you a single parent and shared implementation. But a class can extend only one class - so how do you give unrelated classes a common capability? That's what interfaces are for: a contract many classes can implement, and the topic of the next page.