Polymorphie OOP Grundlagen – Dynamische Bindung, Überschreiben, Überladen, Generics

Dieser Beitrag ist eine Begriffserklärung zur Polymorphie in der OOP – inklusive Prüfungsfragen und Tags.

In a Nutshell

Polymorphie ermöglicht, dass ein einheitlicher Aufruf auf unterschiedliche konkrete Implementierungen angewendet wird, die Auswahl der passenden Methode erfolgt kontextabhängig, meist zur Laufzeit. Ergebnis, flexible, erweiterbare Software mit geringerer Kopplung an konkrete Typen.

Kompakte Fachbeschreibung

Polymorphie bezeichnet die Fähigkeit von Objekten, auf dieselbe Nachricht unterschiedlich zu reagieren, je nach tatsächlichem Typ. Kern ist die dynamische Bindung, Methodenaufrufe werden zur Laufzeit über Dispatch Tabellen, vtable, auf die passende Implementierung aufgelöst. Man unterscheidet Subtyp Polymorphie über Interfaces und Vererbung, parametrische Polymorphie über Generics sowie ad hoc Polymorphie über Überladen. Polymorphes Design stützt das Open Closed Principle, Erweiterungen erfolgen durch neue Typen statt bestehende zu ändern.

Prüfungsrelevante Stichpunkte

• Subtyp Polymorphie, Nutzung über Basistyp oder Interface, konkrete Implementierung wird zur Laufzeit gebunden
• Parametrische Polymorphie, Generics, ein Algorithmus für viele Typen, Typsicher ohne Casting
• Ad hoc Polymorphie, Überladen, gleicher Name, unterschiedliche Parameter, Bindung statisch
• IHK relevant, Unterschied Überschreiben vs. Überladen präzise erklären, dynamische vs. statische Bindung
• Praxis, Strategiemuster nutzt Polymorphie zur Austauschbarkeit von Verhalten ohne if-else Ketten
• Sicherheitsaspekt, Verträge und Invarianten schützen vor fehlerhafter Substitution, Eingaben validieren
• Wirtschaftlichkeit, reduziert Wartungskosten durch Erweiterbarkeit, weniger bedingte Verzweigungen
• Dokumentationspflicht, Interface Verträge, Vorbedingungen, Nachbedingungen, Seiteneffekte eindeutig beschreiben

Kernkomponenten

1. Vertragsschnittstelle, Methoden Signaturen und Semantik
2. Implementierungen, konkrete Klassen, Strategien
3. Dynamischer Dispatch, vtable, Single Dispatch
4. Statischer Dispatch, Kompilierzeit Auflösung beim Überladen
5. Generics, Typ Parameter, Constraints
6. Testbarkeit, Vertrags und Substitutionstests
7. Entwurfsmuster, Strategy, Template Method, Visitor
8. Fehlerbehandlung, Exceptions kompatibel zur Basisschnittstelle
9. Leistungsaspekte, indirekte Aufrufe, Inlining, JIT Optimierung
10. Werkzeugunterstützung, UML, Klassendiagramme, Sequenzdiagramme

Praxisbeispiel

// Subtyp Polymorphie via Strategy
interface PaymentMethod {
Receipt pay(int cents)
}

class CreditCard implements PaymentMethod {
public Receipt pay(int cents) {
// Autorisierung, Clearing
return new Receipt("credit card", cents)
}
}

class PayPal implements PaymentMethod {
public Receipt pay(int cents) {
// Token, Capture
return new Receipt("paypal", cents)
}
}

class CheckoutService {
private PaymentMethod method
public CheckoutService(PaymentMethod method) { this.method = method }
public Receipt checkout(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positiver Betrag erforderlich")
return method.pay(cents)
}
}

Erklärung: CheckoutService spricht nur mit der Schnittstelle PaymentMethod, konkrete Implementierungen werden austauschbar genutzt.

Vorteile und Nachteile

Vorteile

• Klare Trennung von Vertrag und Implementierung
• Bessere Erweiterbarkeit, reduzierte bedingte Logik
• Höhere Testbarkeit durch Mocks und Stubs
• Fördert Wiederverwendung und Kapselung

Nachteile

• Indirekte Aufrufe erschweren Debugging und Performanceanalyse
• Falsche oder schwammige Verträge führen zu Substitutionsfehlern
• Zu komplexe Hierarchien erhöhen kognitive Last

Typische Prüfungsfragen (mit Kurzantwort)

1. Polymorphie im OOP Kontext? Fähigkeit, dass unterschiedliche Objekte über denselben Vertrag angesprochen werden und zur Laufzeit typabhängige Implementierungen ausführen.

2. Überladen vs. Überschreiben? Überladen, gleiche Methode, andere Parameter, statische Bindung, Überschreiben, geerbte Methode wird mit gleicher Signatur neu implementiert, dynamische Bindung.

3. Unterstützt Open Closed Principle? Neue Varianten werden als neue Implementierungen eines bestehenden Interfaces ergänzt, bestehender Code bleibt unverändert.

4. Liskov Substitution Principle fordert? Unterklassen und Implementierungen müssen die Versprechen des Basistyps einhalten, Vorbedingungen nicht verschärfen, Nachbedingungen nicht abschwächen, Invarianten wahren.

5. Praxisbeispiel ohne if-else Kaskade? Zahlungsarten als Strategien hinter PaymentMethod, Auswahl erfolgt über die konkrete Implementierung, nicht über Fallunterscheidungen.

6. Arten von Polymorphie? Subtyp Polymorphie, parametrisierte Polymorphie über Generics, ad hoc Polymorphie über Überladen, seltener Mehrfachdispatch, Visitor.

7. Polymorphie effektiv testen? Vertrags Test Suite gegen das Interface definieren und gegen alle Implementierungen ausführen, zusätzlich Mock basierte Interaktionstests.

8. Duck Typing und Grenzen? Verhalten gilt als gültig, wenn die benötigten Methoden vorhanden sind, keine explizite Typbeziehung nötig, flexibel, aber weniger Kompilierzeit Sicherheit.

Wichtigste Quellen

1. https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html
2. https://de.wikipedia.org/wiki/Polymorphie_(Programmierung)
3. https://martinfowler.com/bliki/Polymorphism.html