Java-Vererbung: extends, super und Überschreiben

Vererbung ist Wiederverwendung nach dem "ist-ein"-Prinzip

Vererbung erlaubt es einer neuen Klasse, auf einer bestehenden aufzubauen. Die neue Klasse -die Unterklasse- erhält automatisch die Felder und Methoden der Oberklasse und fügt dann hinzu oder ändert, was sie braucht. Du greifst dazu, wenn ein Typ eine speziellere Ausprägung eines anderen ist: ein Dog ist ein Animal, ein SavingsAccount ist ein BankAccount.

Du schreibst es mit dem Schlüsselwort extends. Alles, was im Elternteil public oder protected ist, steht im Kind zur Verfügung, ohne dass du es neu schreiben musst.

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); }   // name nach oben an Animal weitergeben

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

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog("Rex");
        d.eat();    // von Animal geerbt
        d.bark();   // in Dog definiert
    }
}

Dog deklariert weder name noch eat(), und doch besitzt es beides. Genau das ist der Sinn: gemeinsames Verhalten lebt an einer einzigen Stelle.

super: den Elternteil erreichen

Der Konstruktor einer Unterklasse muss dafür sorgen, dass der Elternteil zuerst aufgebaut wird. Das tust du mit super(...), was den Konstruktor des Elternteils aufruft und die erste Anweisung im Konstruktor der Unterklasse sein muss. Lässt du es weg, fügt Java stillschweigend einen Aufruf des argumentlosen Konstruktors des Elternteils ein - und wenn der Elternteil keinen solchen Konstruktor hat, lässt sich der Code nicht kompilieren.

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);     // zuerst den Konstruktor von Account ausführen
        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);
    }
}

Die Ausgabe zeigt, dass der Konstruktor des Elternteils vor dem Rumpf des Kindes läuft - die Konstruktion fließt von der Spitze der Hierarchie nach unten.

Methoden überschreiben

Eine Unterklasse kann eine geerbte Methode ersetzen, indem sie sie mit derselben Signatur neu definiert. Das ist das Überschreiben, und du solltest es immer mit @Override kennzeichnen. Die Annotation ist nicht erforderlich, aber sie lässt den Compiler prüfen, ob du tatsächlich eine Methode des Elternteils getroffen hast - sie fängt Tippfehler wie tostring() statt toString() ab, die sonst stillschweigend eine völlig neue Methode erzeugen würden.

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());   // jedes führt seine eigene Version aus
        }
    }
}

Obwohl das Array vom Typ Animal ist, führt jedes Element seine eigene speak()-Methode aus. Java wählt die Methode anhand des tatsächlichen Objekts zur Laufzeit aus, nicht anhand des deklarierten Typs der Variablen - das ist die Grundlage des Polymorphismus.

Die Version des Elternteils mit super.method() aufrufen

Überschreiben muss die Arbeit des Elternteils nicht wegwerfen. Verwende super.method(), um die geerbte Version auszuführen und sie dann zu ergänzen:

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);   // den Elternteil wiederverwenden, dann erweitern
    }
}

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

Ohne super. würde der Aufruf von log innerhalb von TimestampLogger.log sich selbst aufrufen und endlos rekursieren. super. bedeutet ausdrücklich "die Version des Elternteils".

Geerbte Felder und Zugriff

Eine Unterklasse sieht die public- und protected-Member des Elternteils, aber nicht dessen private-Member. private-Felder existieren weiterhin im Objekt - die eigenen Methoden des Elternteils können auf sie zugreifen - aber die Unterklasse kann sie nicht direkt referenzieren. Verwende protected, wenn du möchtest, dass Unterklassen Zugriff haben, während ein Member vor nicht verwandtem Code verborgen bleibt.

class Base {
    private int secret;      // für Unterklassen unsichtbar
    protected int shared;    // für Unterklassen sichtbar
}

class Derived extends Base {
    void demo() {
        shared = 5;          // OK
        // secret = 5;       // Kompilierfehler - private in Base
    }
}

Auch deshalb muss der Konstruktor einer Unterklasse oft super(...) aufrufen: Es ist die einzige Möglichkeit, den privaten Zustand des Elternteils zu initialisieren.

Vererbung mit final stoppen

Manchmal soll eine Klasse überhaupt nicht erweitert werden - String ist genau aus diesem Grund final. Eine Klasse als final zu markieren, verbietet das Ableiten von Unterklassen; eine Methode als final zu markieren, verbietet ihr Überschreiben, erlaubt aber weiterhin das Erweitern der Klasse.

final class Constants { }            // kann nicht abgeleitet werden

class Config {
    final void load() { }            // Unterklassen dürfen Config erweitern,
                                     // aber load() nicht überschreiben
}

Greife zu final, wenn das Verhalten einer Klasse im gesamten Programm garantiert und unveränderlich sein muss - es ist ein bewusstes "nicht erweitern"-Signal, nicht die Standardeinstellung.

Eine häufige Stolperfalle: Komposition bevorzugen, wenn es kein "ist-ein" ist

Vererbung ist verlockend, weil sie Code wiederverwendet, aber sie koppelt das Kind eng an den Elternteil. Wenn die Beziehung kein echtes "ist-ein" ist - etwa ein Car, das zufällig einen Engine braucht - mach nicht Car extends Engine. Ein Auto hat einen Motor, es ist keiner. Modelliere das stattdessen mit einem Feld (Komposition):

class Car {
    private Engine engine = new Engine();   // Car HAT-EIN Engine

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

Verwende Vererbung nur, wenn die Unterklasse wirklich eine spezialisierte Form der Oberklasse ist und du ihr Verhalten erben und ersetzen willst.

Als Nächstes: Schnittstellen

Vererbung mit extends gibt dir einen einzigen Elternteil und eine gemeinsame Implementierung. Aber eine Klasse kann nur eine einzige Klasse erweitern - wie gibst du also nicht verwandten Klassen eine gemeinsame Fähigkeit? Genau dafür gibt es Schnittstellen: ein Vertrag, den viele Klassen implementieren können, und das Thema der nächsten Seite.