Komposition vs. Vererbung.

Du kannst Code auf zwei Arten wiederverwenden: erben (extends) oder ein Objekt als Feld halten und an es delegieren. Anfänger greifen reflexartig zur Vererbung, weil sie zuerst gelehrt wird. Fortgeschrittene Programmierung fragt aber: war das die richtige Wahl? Dieses Topic zeigt, wann Vererbung trägt (echte ist ein-Beziehung) und wann sie zur Falle wird, und warum die Standard-Empfehlung lautet: im Zweifel Komposition (Joshua Bloch, Effective Java, Item 18).

Was du können musst:

• IS-A vs. HAS-A sicher unterscheiden und einer Modellierung zuordnen
• Komposition als Feld + Delegation implementieren
• das Fragile-Base-Class-Problem erklären (warum Vererbung Kapselung bricht)
• die kombinatorische Explosion von Vererbungs-Hierarchien erkennen
• begründen, wann Vererbung trotzdem richtig ist (Liskov, designed for extension)

Die Idee in einem Satz

Vererbung modelliert "ein X ist ein Y" und übernimmt die Implementierung der Oberklasse; Komposition modelliert "ein X hat ein Y", hält das Y als Feld und leitet Aufrufe daran weiter (Delegation).

Das Problem: Vererbung für Code-Reuse

Du brauchst einen Stack (Stapel: nur push und pop). ArrayList kann doch schon alles, also erbst du einfach:

// ANTI-PATTERN: Vererbung nur um Code zu sparen
class Stack<E> extends ArrayList<E> {
    void push(E e) { add(e); }
    E pop() { return remove(size() - 1); }
}

Sieht praktisch aus, ist aber kaputt: dein Stack hat jetzt auch add(int index, E e), remove(int index), set(...), clear(), geerbt von ArrayList. Jemand kann stack.add(0, x) aufrufen und mitten in den Stapel schreiben. Die Invariante "Zugriff nur oben" ist hin. Du hast die ganze Schnittstelle der Oberklasse mitgeerbt, auch die Teile, die du gar nicht willst.

// HAS-A: Stack HÄLT eine Liste und zeigt nur push/pop nach außen
class Stack<E> {
    private final List<E> elems = new ArrayList<>();   // Komposition

    void push(E e) { elems.add(e); }
    E pop() {
        if (elems.isEmpty()) throw new EmptyStackException();
        return elems.remove(elems.size() - 1);          // Delegation
    }
    boolean isEmpty() { return elems.isEmpty(); }
}

Mit Komposition entscheidest du, welche Methoden nach außen sichtbar sind. Die Liste ist private, niemand kann an der Invariante vorbei.

Das Fragile-Base-Class-Problem

Vererbung bricht Kapselung: die Subklasse hängt an Implementierungsdetails der Oberklasse, die sich ändern können. Der Klassiker (aus Bloch, Effective Java): ein HashSet, das mitzählt, wie viele Elemente je hinzugefügt wurden.

class ZaehlendesSet<E> extends HashSet<E> {
    private int hinzugefuegt = 0;

    @Override public boolean add(E e) {
        hinzugefuegt++;
        return super.add(e);
    }
    @Override public boolean addAll(Collection<? extends E> c) {
        hinzugefuegt += c.size();
        return super.addAll(c);
    }
    int getHinzugefuegt() { return hinzugefuegt; }
}

var s = new ZaehlendesSet<String>();
s.addAll(List.of("a", "b", "c"));
System.out.println(s.getHinzugefuegt());   // erwartet 3 ... liefert 6!

Warum 6? Weil HashSet.addAll intern selbst add aufruft (self-use). Also zählt addAll die 3 Elemente, und das von ihm aufgerufene überschriebene add zählt sie nochmal. Du müsstest wissen, dass addAll sich auf add abstützt, ein undokumentiertes Implementierungsdetail, das in der nächsten Java-Version anders sein kann.

Dieses konkrete Beispiel steht für ein allgemeines Muster, die fragile Basisklasse: deine Subklasse kann brechen, ohne dass du sie anfasst, nur weil sich die Oberklasse intern ändert. Komposition hat dieses Problem nicht: das gehaltene Objekt arbeitet über seine eigene öffentliche Schnittstelle und ruft keine überschriebenen Methoden deiner Klasse auf, es entsteht keine implizite self-use-Kopplung (außer du gibst ihm bewusst einen Callback).

Delegation, Flexibilität und die Klassen-Explosion

Delegation heißt: deine Methode macht die Arbeit nicht selbst, sondern reicht sie an das gehaltene Objekt weiter. Das entkoppelt: du programmierst gegen ein Interface, nicht gegen eine konkrete Oberklasse, und kannst das gehaltene Objekt zur Laufzeit austauschen (das ist im Kern das Strategy-Pattern). Strategy heißt hier: das austauschbare Verhalten steckt in einem eigenen Objekt, nicht fest verdrahtet in der Auto-Klasse.

interface Antrieb { void starten(); }

class Elektro implements Antrieb {
    public void starten() { System.out.println("leise surren"); }
}
class Benzin implements Antrieb {
    public void starten() { System.out.println("brummen"); }
}

class Auto {
    private Antrieb antrieb;                     // HAS-A
    Auto(Antrieb antrieb) { this.antrieb = antrieb; }
    void setAntrieb(Antrieb a) { this.antrieb = a; }   // zur Laufzeit wechselbar!
    void losfahren() { antrieb.starten(); }      // Delegation
}

var auto = new Auto(new Benzin());
auto.losfahren();              // brummen
auto.setAntrieb(new Elektro());
auto.losfahren();              // leise surren

Mit Vererbung müsstest du jede Kombination als eigene Klasse bauen: BenzinAuto, ElektroAuto, BenzinLKW, ElektroLKW. Bei F Fahrzeug-Typen und A Antrieben sind das F × A Klassen (multiplikativ). Mit Komposition: F + A + 1 Klassen (additiv). Genau das kannst du im interaktiven Tab durchspielen.

Wann Vererbung trotzdem richtig ist

Vererbung ist nicht verboten, sie ist nur kein Default. Sie passt, wenn alle Punkte gelten:

1. Es ist eine echte IS-A-Beziehung ("ein Hund ist ein Tier").
2. Das Liskov-Substitutionsprinzip hält: überall, wo die Oberklasse erwartet wird, darf die Subklasse stehen, ohne dass etwas bricht.
3. Die Oberklasse ist für Vererbung entworfen und dokumentiert (oder du kontrollierst sie, gleiches Paket). Bloch: "Inheritance is appropriate only ... within a package, or when ... designed and documented for extension."

Klausur-Faustregeln

1. Sprachtest IS-A vs. HAS-A. "Ein Auto ist ein Motor"? Nein, ein Auto hat einen Motor, also Komposition. Sag den Satz laut, dann weißt du es.

2. Im Zweifel Komposition (Bloch, Item 18). Sie ist lose gekoppelt, flexibler und bricht keine Kapselung. Vererbung ist die Ausnahme, die du begründen musst.

3. Komposition = Feld + Delegation. Halte das andere Objekt private als Feld und leite nur die Methoden weiter, die du wirklich anbieten willst. So bleibt die Schnittstelle minimal.

4. Vererbung nur bei echtem IS-A plus Liskov. Die Subklasse muss überall für die Oberklasse einsetzbar sein. Kannst du das nicht garantieren, ist Vererbung falsch.

5. Verhalten zur Laufzeit wechselbar nötig? Komposition. Bei Vererbung steht die Klasse eines Objekts mit new fest (ein ElektroAuto bleibt eines) und lässt sich nicht mehr austauschen; ein per Komposition gehaltenes Objekt (Strategy) wechselst du dagegen jederzeit per Setter.

6. Vererbung nur bei kontrollierter/dokumentierter Basisklasse. Eine fremde Klasse zu erweitern (z.B. ArrayList) ist riskant, weil du an ihre internen Aufrufe (self-use) gebunden bist.

Häufige Stolpersteine

1. Vererbung nur zum Code-Sparen. Stack extends ArrayList erbt add(index), remove(index) usw. und zerstört die Stapel-Invariante. Reuse rechtfertigt keine Vererbung, die Beziehung muss IS-A sein.

2. Fragile Basisklasse durch self-use. addAll ruft intern add; überschreibst du beide, zählst du doppelt. Subklassen hängen an undokumentierten Implementierungsdetails der Oberklasse.

3. Oberflächliches IS-A bricht Liskov. "Quadrat ist ein Rechteck" klingt richtig, aber setBreite/setHoehe verhalten sich beim Quadrat anders, Code, der mit Rechtecken rechnet, bricht. Sprache reicht nicht, das Verhalten muss passen.

4. Tiefe Vererbungstürme. Fünf Ebenen extends sind schwer nachzuvollziehen; eine Änderung oben kann unten alles brechen. Komposition bleibt flach und lokal.

5. Komposition mit Aggregation verwechseln. In UML ist ◆ (Komposition) eine starke Ganzes-Teil-Beziehung mit gemeinsamer Lebensdauer (eine Rechnung besitzt ihre Posten, die mit ihr verschwinden), ◇ (Aggregation) eine schwache (ein Team hat Spieler, die auch ohne das Team existieren). In Java gibt es dafür keine syntaktische Unterscheidung: beide sind ein Feld, der Unterschied liegt allein in Intention und Lebenszyklus.

6. "Java kann keine Mehrfachvererbung" als Sackgasse sehen. Du brauchst sie nicht: beliebig viele HAS-A-Felder plus mehrere Interfaces ersetzen Mehrfachvererbung sauber und ohne Diamant-Problem.

Klassen-Explosion live

Dasselbe Problem, zwei Designs: links Vererbung (eine Klasse pro Fahrzeug-Antrieb-Kombination), rechts Komposition (Fahrzeug hält einen Antrieb über ein Interface).

Probier folgendes:

• Starte bei 2 Fahrzeugen × 2 Antrieben. Beide Seiten sind noch klein.
• Klick + Antriebsart (z.B. Hybrid): die Vererbungs-Seite bekommt pro Fahrzeug eine neue Klasse, die Komposition-Seite genau eine.
• Füge noch ein paar Typen hinzu und beobachte die Formel: Vererbung F × A (multiplikativ) gegen Komposition F + A + 1 (additiv).

Das ist der praktische Grund für "favor composition over inheritance": neue Anforderungen kosten bei Komposition eine Klasse, bei Vererbung eine ganze Reihe.

Faustregel zum Mitnehmen: Wenn dein Problem zwei unabhängige Achsen hat (hier: Fahrzeug-Art und Antrieb), modelliere die eine als Klasse und die andere als gehaltenes Objekt, nicht beide über Vererbung. Sonst multiplizieren sich die Achsen zu einer Klassen-Explosion. Komposition hält jede Achse separat und kombiniert sie zur Laufzeit, das ist genau die Idee hinter dem Strategy-Pattern.