Polymorphie in Java: eine Schnittstelle, viele Formen

Eine Referenz, viele Typen

Polymorphie ist der Lohn von Vererbung und Schnittstellen. Sie bedeutet, dass eine einzige als Elternklasse (oder Schnittstelle) typisierte Variable ein Objekt eines beliebigen Untertyps halten kann, und wenn du eine Methode darauf aufrufst, führt Java die Version aus, die zur tatsächlichen Klasse des Objekts gehört - nicht die Version, die der deklarierte Typ der Variablen nahelegt.

Die Grundlage hast du bereits auf der Seite zur Vererbung gesehen: Eine Unterklasse überschreibt eine Methode ihrer Elternklasse. Polymorphie macht dieses Überschreiben erst lohnenswert - sie erlaubt es dir, Code gegen den allgemeinen Typ zu schreiben und jedes konkrete Objekt auf seine eigene Weise verhalten zu lassen.

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

class Dog extends Animal {
    String speak() { return "Woof"; }
}

class Cat extends Animal {
    String speak() { return "Meow"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // eine Eltern-Referenz, die ein Kindobjekt hält
        Animal b = new Cat();

        System.out.println(a.speak());   // Woof
        System.out.println(b.speak());   // Meow
    }
}

Sowohl a als auch b sind als Animal deklariert, dennoch gibt jedes seinen eigenen Laut aus. Diese Wahl geschieht zur Laufzeit anhand des realen Objekts.

Dynamischer Methodenaufruf

Der Mechanismus dahinter ist der dynamische Methodenaufruf (dynamic method dispatch): Bei einer überschriebenen Instanzmethode betrachtet die JVM die Laufzeitklasse des Objekts, um zu entscheiden, welche Implementierung aufgerufen wird. Der Compiler prüft nur, ob die Methode auf dem deklarierten Typ existiert; die eigentliche Auswahl wird bis zur Programmausführung aufgeschoben.

Genau das ermöglicht es einer einzigen Schleife, eine ganze Mischung von Typen zu verarbeiten, ohne jemals zu fragen, was jedes davon ist:

import java.util.List;

class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

public class Main {
    public static void main(String[] args) {
        List<Shape> shapes = List.of(new Circle(1), new Square(2), new Circle(3));

        double total = 0;
        for (Shape shape : shapes) {
            total += shape.area();   // jeder Aufruf wird an die reale Unterklasse weitergeleitet
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

Die Schleife kennt nur Shape. Füge später ein Triangle extends Shape hinzu, und dieser Code funktioniert unverändert weiter - genau das ist der Sinn. Der Code hängt von der Abstraktion ab, nicht von der konkreten Liste der Typen.

Upcasting und Downcasting

Einen Dog in einer Animal-Variablen zu speichern, ist Upcasting - das Aufsteigen in der Hierarchie zu einem allgemeineren Typ. Es ist immer sicher und Java macht es implizit, denn jeder Dog ist ein Animal.

In die andere Richtung zu gehen, ist Downcasting - eine Eltern-Referenz nehmen und sie als einen bestimmten Untertyp behandeln. Das ist nur gültig, wenn das Objekt wirklich dieser Untertyp ist, daher musst du den Cast explizit schreiben und riskierst eine ClassCastException, wenn du dich irrst:

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal { }

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // Upcast - implizit, sicher

        Dog d = (Dog) a;        // Downcast - explizit, gültig, weil a wirklich ein Dog ist
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // kompiliert, wirft aber zur Laufzeit eine ClassCastException
        wrong.fetch();
    }
}

Der letzte Cast kompiliert problemlos - der Compiler kann nicht beweisen, dass er falsch ist - fliegt aber bei der Ausführung auseinander, weil ein Cat kein Dog ist. Mache niemals ein Downcast auf gut Glück.

Downcasts mit instanceof absichern

Prüfe vor einem Downcast den realen Typ mit instanceof. Modernes Java erlaubt es dir, das Ergebnis im selben Ausdruck zu binden (Pattern Matching für instanceof), sodass du den separaten Cast einsparst:

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal {
    void scratch() { System.out.println("scratching"); }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat(), new Dog() };

        for (Animal animal : animals) {
            if (animal instanceof Dog dog) {     // prüft den Typ UND bindet dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof gibt für null false zurück, daher schützt dich die Prüfung auch vor einer NullPointerException. Wenn du dich jedoch dabei ertappst, lange instanceof-Ketten zu schreiben, ist das oft ein Zeichen dafür, dass das Verhalten als überschriebene Methode in die Klassen gehört - lass die Polymorphie die Verzweigung für dich übernehmen.

Overriding vs. Overloading

Die beiden klingen ähnlich, haben aber nichts miteinander zu tun, und sie zu verwechseln ist eine klassische Quelle von Verwirrung.

Overriding (Überschreiben) ist eine Unterklasse, die eine Methode der Elternklasse mit identischer Signatur ersetzt. Es wird zur Laufzeit über den Typ des Objekts aufgelöst - das ist die Polymorphie, die wir verwendet haben.

Overloading (Überladen) ist eine Klasse mit mehreren Methoden gleichen Namens, aber unterschiedlichen Parameterlisten. Es wird zur Kompilierzeit über die Argumenttypen aufgelöst, ohne dass ein Laufzeitaufruf beteiligt ist:

public class Main {
    static String describe(int x)    { return "int: " + x; }
    static String describe(double x) { return "double: " + x; }
    static String describe(String x) { return "String: " + x; }

    public static void main(String[] args) {
        System.out.println(describe(5));      // int: 5
        System.out.println(describe(5.0));    // double: 5.0
        System.out.println(describe("five")); // String: five
    }
}

Der Compiler wählt das passende describe allein anhand des statischen Typs des Arguments. Es ist kein Eltern-/Kindobjekt beteiligt, also ist das keine Laufzeitpolymorphie - es verwendet lediglich einen Methodennamen wieder.

Ein häufiger Fallstrick: Felder sind nicht polymorph

Nur Instanzmethoden werden zur Laufzeit aufgerufen. Felder und statische Methoden werden über den deklarierten Typ aufgelöst, was viele stolpern lässt:

class Parent {
    String label = "parent";
    String name() { return "Parent"; }
}

class Child extends Parent {
    String label = "child";          // verdeckt, überschreibt nicht
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent  - das Feld nutzt den deklarierten Typ
        System.out.println(p.name());   // Child   - die Methode nutzt den Laufzeittyp
    }
}

p.name() führt die Version von Child aus (Polymorphie), aber p.label liest das Feld von Parent, weil Felder verdeckt und nicht überschrieben werden. Die Lösung ist einfach: Halte Felder private und greife nur über Methoden darauf zu, damit der polymorphe Aufruf immer gewinnt.

Als Nächstes: Zugriffsmodifikatoren

Polymorphie funktioniert nur dann sauber, wenn Unterklassen die richtigen Member sehen und überschreiben können, während der Rest deines Codes nicht hineingreifen und Invarianten brechen kann. Dieses Gleichgewicht wird durch die Zugriffe public, protected, private und paketprivat gesteuert - die Zugriffsmodifikatoren, als Nächstes.