Overriding vs Overloading: Der Polymorphismus-Fallstrick in Java

Polymorphismus klingt irgendwie erstmal nach einem Wort aus dem Biologieunterricht oder nach einem mathematischen Konstrukt. In Java steckt dahinter aber etwas sehr Praktisches: Du schreibst Code, der mit verschiedenen konkreten Klassen arbeiten kann, ohne dass du überall Sonderfälle einbaust. Das macht deinen Code robuster, leichter testbar und oft auch deutlich übersichtlicher.

Wenn du jemals eine lange Kette aus if else gesehen hast, die abhängig von einem Typ etwas anderes tut, dann war das meistens ein Signal: Hier könnte Polymorphismus helfen. Statt zu fragen "Was bist du?" und dann zu entscheiden, lässt du das Objekt selbst das richtige Verhalten liefern.

Was Polymorphismus in Java wirklich bedeutet

Wörtlich heißt Polymorphismus "viele Formen". In der objektorientierten Programmierung bedeutet das: Ein Objekt kann über einen allgemeineren Typ angesprochen werden, zum Beispiel über eine Oberklasse oder ein Interface. Entscheidend ist, dass zur Laufzeit trotzdem die passende Implementierung ausgeführt wird.

Du kennst das vermutlich schon, ohne es so zu nennen: Wenn eine Methode einen Parameter vom Typ List erwartet, kann sie mit ArrayList, LinkedList oder jeder anderen List Implementierung arbeiten. Der Code bleibt gleich, nur das konkrete Verhalten kann sich unterscheiden, zum Beispiel Performance bei bestimmten Operationen.

In Java begegnen dir dabei zwei Dinge:

• Subtyping: Eine Klasse "ist ein" anderer Typ, zum Beispiel "Cat ist ein Animal" oder "MysqlRepository ist ein Repository".
• Dynamische Bindung: Welche überschreibende Methode wirklich läuft, entscheidet sich zur Laufzeit anhand des echten Objekts.

Das ist der Kern. Polymorphismus ist keine Magie, sondern eine saubere Vereinbarung: "Ich rede mit dir über ein Interface oder eine Oberklasse, und du lieferst das passende Verhalten."

Ganz wichtig: Polymorphismus betrifft Instanzmethoden, die überschrieben werden können. Statische Methoden sind nicht polymorph, weil sie zur Compilezeit an den Typ gebunden werden. Und wenn du eine Methode als final markierst, kann sie nicht überschrieben werden, also gibt es dort auch kein "zur Laufzeit auswählen".

Ein kleines Beispiel mit Interface und Überschreiben

Ein simples Szenario: Du willst Zahlungen ausführen. Ob das per Kreditkarte oder PayPal passiert, ist für den Aufrufer erstmal egal. Er will nur "bezahlen". Genau dafür ist ein Interface ideal.

public interface PaymentMethod {
    void pay(int cents);
}

public class CreditCard implements PaymentMethod {
    @Override
    public void pay(int cents) {
        System.out.println("Paid by credit card: " + cents);
    }
}

public class Paypal implements PaymentMethod {
    @Override
    public void pay(int cents) {
        System.out.println("Paid by PayPal: " + cents);
    }
}

Jetzt kommt der polymorphe Teil. Du arbeitest mit dem Typ PaymentMethod, aber du kannst unterschiedliche Implementierungen übergeben:

public class CheckoutService {
    public void checkout(PaymentMethod method, int cents) {
        method.pay(cents);
    }
}

Der CheckoutService muss nicht wissen, welche konkrete Klasse dahinter steckt. Er ruft nur pay auf. Wenn du später ApplePay hinzufügst, änderst du den Service nicht, du lieferst einfach eine weitere Implementierung. Genau das ist Polymorphismus in der Praxis.

In der Realität sieht das oft so aus, dass du mehrere PaymentMethod Objekte in einer Liste hast und alle gleich behandelst:

List<PaymentMethod> methods = List.of(new CreditCard(), new Paypal());
methods.forEach(m -> m.pay(500));

Die Schleife kennt nur PaymentMethod. Trotzdem führt jedes Objekt seine eigene pay Implementierung aus. Du bekommst also unterschiedliche Ergebnisse, ohne dass du irgendwo nach dem Typ fragen musst.

Wenn du in IntelliJ debugst und bei m.pay(500) reinspringst, landest du je nach Objekt in CreditCard.pay oder Paypal.pay. Das ist dynamische Bindung, und sie ist in Java Standardverhalten bei Instanzmethoden.

Noch ein typisches Beispiel ist eine Oberklasse:

public abstract class Animal {
    public abstract String sound();
}

public class Dog extends Animal {
    @Override
    public String sound() {
        return "Woof";
    }
}

Auch hier gilt: Wenn du Animal referenzierst, entscheidet das konkrete Objekt, welches sound läuft. Der Aufrufer schreibt also nicht "wenn Dog dann Woof", sondern sagt nur "gib mir deinen Sound".

Woran Polymorphismus in echten Projekten scheitert

In echten Codebasen passiert selten der Fehler "Polymorphismus nicht verstanden". Häufiger sind es handfeste Stolperfallen, die du gut vermeiden kannst.

Der erste Klassiker: Du greifst zu früh auf konkrete Klassen zu. Wenn du überall new CreditCard() direkt in deinem Code verteilst, baust du eine harte Kopplung ein. Später willst du tauschen, testen oder konfigurieren, und plötzlich hängt alles an dieser einen Klasse. Besser ist, dass dein Code nur den allgemeinen Typ kennt und die konkrete Auswahl an einer Stelle passiert. In JavaEE ist das oft der Container, in einem kleineren Projekt vielleicht eine Factory oder schlicht der Konstruktor.

Der zweite Klassiker: Du nutzt instanceof als Dauerlösung. instanceof ist nicht grundsätzlich verboten, aber wenn es sich häuft, ist das meist ein Zeichen dafür, dass dir eine Abstraktion fehlt. Viele instanceof Blöcke lassen sich durch ein Interface oder eine passende Oberklasse ersetzen, die genau das Verhalten anbietet, das du gerade abfragen willst.

Der dritte Klassiker: Du vermischst Polymorphismus mit "alles in ein Interface pressen". Ein Interface ist kein Müllcontainer für jeden beliebigen Methodenaufruf. Wenn du Methoden reinpackst, die nur eine Implementierung sinnvoll erfüllen kann, machst du dir selbst das Leben schwer. Gute Interfaces sind klein, klar benannt und beschreiben ein zusammenhängendes Verhalten.

Der vierte Klassiker: Verwechslung von Overloading und Overriding. Overloading ist, wenn du mehrere Methoden mit gleichem Namen aber unterschiedlichen Parametern hast. Welche davon genommen wird, entscheidet Java zur Compilezeit anhand der Typen, die im Code stehen. Overriding ist das Überschreiben in einer Unterklasse. Welche Methode läuft, entscheidet sich zur Laufzeit anhand des Objekts. Polymorphismus hängt an Overriding, nicht an Overloading.

Ein Mini-Beispiel, das oft überrascht:

void print(Animal a) { 
  System.out.println("animal"); 
}

void print(Dog d) { 
  System.out.println("dog"); 
}

Animal a = new Dog();
print(a); // Ausgabe: "animal"

Warum? Weil die Auswahl der überladenen Methode auf dem statischen Typ Animal basiert. Overriding würde hier anders wirken, aber Overloading eben nicht.

Und noch etwas, das du dir früh merken solltest: Polymorphismus ersetzt keine saubere Modellierung. Wenn du für jeden Sonderfall eine neue Klasse baust, aber die eigentliche Domäne nicht verstanden hast, wird es schnell unübersichtlich. Umgekehrt bringt dir eine "Super-Abstraktion", die alles können soll, auch nichts. Sinnvoll wird Polymorphismus dort, wo du wirklich austauschbares Verhalten hast, zum Beispiel verschiedene Speichermedien, unterschiedliche Validierungsstrategien oder mehrere Wege, dieselbe Operation auszuführen.

Fazit

Polymorphismus bedeutet in Java vor allem: Du programmierst gegen Oberklassen oder Interfaces und verlässt dich darauf, dass das konkrete Objekt zur Laufzeit das passende Verhalten liefert. Dadurch musst du weniger if else Ketten schreiben, dein Code bleibt offen für Erweiterungen und du kannst Teile einfacher testen.

Wenn du Polymorphismus sinnvoll einsetzen willst, halte deine Abstraktionen klein und ehrlich: Ein Interface beschreibt eine Fähigkeit, keine Wunschliste. Nutze Overriding für echtes Austauschverhalten und sei vorsichtig bei Overloading, weil dort der Compiler entscheidet. Wenn du diese Unterschiede im Kopf hast, wird vieles in Java plötzlich klarer, und du schreibst automatisch flexibleren Code.