Vererbung OOP Grundlagen – Basisklasse, Unterklasse, Überschreiben, Polymorphie, Liskov

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

In a Nutshell

Vererbung erlaubt es, gemeinsame Eigenschaften und Verhalten in einer Basisklasse zu definieren und in Unterklassen wiederzuverwenden. Ziel ist Wiederverwendung, Polymorphie und klare Typbeziehungen, ohne redundanten Code.

Kompakte Fachbeschreibung

Vererbung bildet eine ist-ein Beziehung zwischen Typen, bei der eine Unterklasse alle öffentlich, geschützten Merkmale der Basisklasse erbt und erweitern oder überschreiben kann. Sie ermöglicht Polymorphie, dynamische Bindung und späte Methodenauswahl, Dispatch erfolgt über den tatsächlichen Objekttyp zur Laufzeit. Man unterscheidet Implementierungsvererbung von Schnittstellenvererbung, etwa via Interfaces. Das Liskov Substitution Principle fordert, dass Unterklassen sich wie ihre Basisklasse verhalten, ohne Klienten zu überraschen. Probleme wie fragile Basisklasse, Diamond Problem, enge Kopplung sprechen für Komposition vor Vererbung wenn nur Wiederverwendung ohne echte ist-ein Beziehung benötigt wird.

Prüfungsrelevante Stichpunkte

• ist-ein Beziehung, korrekt einsetzen, nicht für hat-ein verwenden
• Überschreiben, Override, ermöglicht polymorphes Verhalten, Signatur muss kompatibel bleiben
• Sichtbarkeit, public, protected, private, beeinflusst Vererbbarkeit und Zugriff
• IHK relevant, Unterschiede zwischen Implementierungsvererbung und Interfacevererbung benennen
• Komposition vor Vererbung, geringere Kopplung, bessere Austauschbarkeit in der Praxis
• LSP einhalten, Vorbedingungen nicht verschärfen, Nachbedingungen nicht abschwächen, Invarianten wahren
• Wirtschaftlichkeit, weniger Duplikate, aber Risiko teurer Refactorings bei falscher Hierarchie
• Dokumentationspflicht, Verträge, Nebenwirkungen, Überschreibungsregeln, Erweiterungspunkte festhalten

Kernkomponenten

1. Basisklasse, Superklasse mit gemeinsamen Attributen und Methoden
2. Unterklasse, Subklasse die erbt, erweitert, überschreibt
3. Überschreiben, Override mit dynamischem Dispatch
4. Überladen, Overload, gleiche Methode, andere Parameter, keine Vererbung nötig
5. Abstrakte Klasse, gemeinsame Basis mit teilweise implementiertem Verhalten
6. Interface, reine Vertragsschnittstelle für Mehrfachvererbung von Typen
7. Finalität, final Versiegelung gegen Überschreiben, Erben
8. Konstruktorverkettung, super Aufruf, Initialisierungsreihenfolge
9. Zugriffsrechte, protected für Erweiterer, private für strikte Kapselung
10. Test Verfahren, Substitutions und Vertrags Tests, Polymorphie Tests

Praxisbeispiel

// Beispiel, Java ähnliche Syntax mit Vererbung und Polymorphie
abstract class Shape {
public abstract double area()
}

class Rectangle extends Shape {
private double w, h
public Rectangle(double w, double h) {
if (w <= 0 || h <= 0) throw new IllegalArgumentException("positive Maße")
this.w = w
this.h = h
}
@Override
public double area() {
return w * h
}
}

class Circle extends Shape {
private double r
public Circle(double r) {
if (r <= 0) throw new IllegalArgumentException("positiver Radius")
this.r = r
}
@Override
public double area() {
return Math.PI * r * r
}
}

// Polymorphe Nutzung
Shape s1 = new Rectangle(3, 4)
Shape s2 = new Circle(2)
double sum = s1.area() + s2.area()

Erklärung: Shape definiert den Vertrag area, Unterklassen implementieren ihn spezifisch, Aufrufe erfolgen polymorph.

Vorteile und Nachteile

Vorteile

• Code Wiederverwendung, Polymorphie
• Klarer Vertrag über gemeinsame Schnittstelle
• Reduktion redundanter Implementationen, einheitliche API für Klienten

Nachteile

• Enge Kopplung an Basisklassenentscheidungen
• Fragile Hierarchien, erschwertes Refactoring
• Diamond Problem bei Mehrfachvererbung, mögliche Verletzung von Kapselung

Typische Prüfungsfragen (mit Kurzantwort)

1. Vererbung angemessen? Wenn eine echte ist-ein Beziehung besteht, Unterklasse kann überall dort eingesetzt werden, wo die Basisklasse erwartet wird.

2. Überschreiben vs. Überladen? Überschreiben ersetzt geerbtes Verhalten gleicher Signatur in der Unterklasse, Überladen definiert mehrere Methoden gleichen Namens mit unterschiedlichen Parametern.

3. Polymorphie im Kontext der Vererbung? Referenztyp kann Objekte von Basisklasse oder Unterklassen halten, Methodenaufrufe binden zur Laufzeit an den tatsächlichen Objekttyp.

4. Warum Komposition vor Vererbung? Komposition reduziert Kopplung, vermeidet starre Hierarchien, erlaubt austauschbare Implementierungen, besser für Wiederverwendung ohne echte ist-ein Beziehung.

5. Rolle von protected? protected erlaubt Unterklassen den Zugriff, kann aber Kapselung schwächen, sparsam einsetzen, bevorzugt private mit Zugriffsmethoden.

6. Liskov Substitution Principle fordert? Vorbedingungen nicht verschärfen, Nachbedingungen nicht abschwächen, Invarianten der Basisklasse einhalten, sonst bricht Substituierbarkeit.

7. Diamond Problem erklären? Mehrfachvererbung zweier Basisklassen mit gemeinsamem Vorfahren führt zu Mehrdeutigkeit, manche Sprachen lösen dies mit virtueller Vererbung.

8. Substituierbarkeit testen? Vertrags Tests gegen die Basisklassen, Interface Spezifikation definieren, dieselben Tests gegen alle Unterklassen instanzen laufen lassen.

Wichtigste Quellen

1. https://docs.oracle.com/javase/specs/
2. https://de.wikipedia.org/wiki/Vererbung_(Programmierung)
3. https://martinfowler.com/articles/inheritance.html