Abstrakte Klassen

Definition

Beispiel 1

Die abstrakte Klasse GeoFigur

Dieses Bild zeigt den Quelltext der abstrakten Klasse Geofigur. Das ganze Projekt können Sie sich übrigens unter "Java-Beispiel 'Heterogene Liste' " anschauen.

Die beiden Methoden anzeigen() und loeschen() in dieser Klasse sind abstrakt, und daher muss auch die gesamte Klasse als abstract deklariert werden:

public abstract class GeoFigur

Die konkrete Unterklasse Kreis

Hier sehen wir den Quelltext der konkreten (also nicht-abstrakten) Unterklasse Kreis. Die beiden abstrakten Methoden anzeigen() und loeschen() werden hier durch konkrete Methoden (Signatur + Implementierung) überschrieben (siehe auch "Überschreiben von Methoden").

Angenommen, wir haben mehrere verschiedene Unterklassen der abstrakten Klasse GeoFigur, beispielsweise Kreis, Rechteck, Quadrat, Dreieck, Fuenfeck und so weiter. Dann könnten wir einen Array bilden, der so aufgebaut ist wie in der folgenden Test-Klasse:

Die Testklasse

Von der abstrakten Oberklasse GeoFigur wird ein einfacher Array angelegt:

GeoFigur[] geoArry = new GeoFigur[6];

In der Methode auffuellen() werden drei Objekte der Klasse Kreis, ein Rechteck-Objekt, ein Dreieck-Objekt und ein Quadrat-Objekt erzeugt und in den Array eingefügt. So entsteht ein heterogener Array, also ein Array mit Elementen unterschiedlichen Datentyps.

Ein weiteres Beispiel finden Sie in dem Artikel "Abstrakte Methoden".

Theorieteil

Dieser Abschnitt wurde von ChatGPT erstellt und von mir dann überarbeitet.

Die Rolle abstrakter Methoden im Klassendesign

Bisher haben wir abstrakte Methoden vor allem formal kennengelernt: als Methoden ohne Implementierung, die in Unterklassen überschrieben werden müssen. Für ein tieferes Verständnis ist jedoch entscheidend, welche Entwurfsfunktion abstrakte Methoden tatsächlich haben.

1. Abstrakte Methoden als Vertrag

Eine abstrakte Methode beschreibt kein konkretes Verhalten, sondern eine verbindliche Zusage, die jede Unterklasse einlösen muss. Die Oberklasse legt damit fest, dass ein bestimmtes Verhalten existieren muss, ohne festzulegen, wie dieses Verhalten konkret umgesetzt wird.

Im Buch-Projekt bedeutet die abstrakte Methode zeigeDetails():

• Jede konkrete Buchklasse muss zusätzliche Details ausgeben.
• Welche Details das sind (Genre, Fachgebiet, Laufzeit usw.), entscheidet die jeweilige Unterklasse.
• Die Oberklasse darf sich darauf verlassen, dass diese Methode existiert.

Abstrakte Methoden wirken damit wie ein Vertrag zwischen Ober- und Unterklasse.

2. Abstrakte Methoden vs. überschreibbare Methoden

Ein wichtiger Unterschied besteht zwischen Methoden, die überschrieben werden dürfen, und solchen, die überschrieben werden müssen:

• Normale Methoden können überschrieben werden, müssen es aber nicht.
• Abstrakte Methoden müssen von jeder nicht-abstrakten Unterklasse implementiert werden.

Diese Unterscheidung ist für das Design entscheidend: Abstrakte Methoden kennzeichnen genau die Stellen, an denen Variation ausdrücklich vorgesehen ist.

3. Sichtbarkeit abstrakter Methoden

Abstrakte Methoden sind in der Praxis fast immer als public oder protected deklariert. Eine abstrakte Methode mit der Sichtbarkeit private wäre sinnlos, da sie von Unterklassen nicht überschrieben werden könnte.

Im Buch-Projekt ist zeigeDetails() bewusst protected, da sie ausschließlich innerhalb der Klassenhierarchie verwendet wird und nicht Teil der öffentlichen Schnittstelle ist. Unterklassen von Buch können also die Methode zeigeDetails() überschreiben, während andere Klasse, die keine Unterklassen von Buch sind, diese Methode noch nicht einmal sehen geschweige denn überschreiben können.

4. Abstrakte Methoden und final-Methoden

Abstrakte Methoden und final-Methoden verfolgen gegensätzliche Ziele:

• Abstrakte Methoden erzwingen Variation.
• final-Methoden verbieten Variation.

In gut entworfenen Klassenhierarchien werden beide Mechanismen gezielt kombiniert: Der feste Ablauf wird durch finale oder nicht überschreibbare Methoden gesichert, während abstrakte Methoden die variablen Teile definieren.

5. Typische Fehlvorstellungen

Gerade bei Studienanfängern treten häufig folgende Missverständnisse auf:

• "Abstrakte Methoden sind einfach leere Methoden."
• "Abstrakte Methoden braucht man nur, wenn man noch nicht weiß, was man tun will."
• "Man kann abstrakte Methoden später einfach weglassen."

Tatsächlich sind abstrakte Methoden ein bewusstes Entwurfsinstrument. Sie dokumentieren die Stellen eines Programms, an denen Erweiterbarkeit vorgesehen und erwünscht ist.

6. Abstrakte Methoden und Design by Contract

Abstrakte Methoden lassen sich sehr gut im Sinne des Konzepts Design by Contract interpretieren. Auch hier wird ein Vertrag zwischen Oberklasse und Unterklassen formuliert – allerdings auf einer anderen Ebene als bei einzelnen Methodenaufrufen.

Während Design by Contract bei konkreten Methoden zwischen Aufrufer und Methode unterscheidet, beschreibt eine abstrakte Methode einen Vertrag zwischen Oberklasse und Unterklasse:

• Die Oberklasse legt fest, dass ein bestimmtes Verhalten existieren muss.
• Die Unterklasse verpflichtet sich, dieses Verhalten konkret zu implementieren.

Im Buch-Projekt bedeutet die abstrakte Methode zeigeDetails(): Jede konkrete Unterklasse von Buch garantiert, dass sie ihre zusätzlichen Informationen selbstständig ausgibt. Die Oberklasse darf sich darauf verlassen und ruft diese Methode im Rahmen der zeige()-Methode auf, ohne den konkreten Inhalt zu kennen.

In diesem Sinne fungiert eine abstrakte Methode als struktureller Vertrag: Die Oberklasse definiert die Schnittstelle und den Ablauf, die Unterklasse garantiert die Einhaltung dieses Vertrags durch eine passende Implementierung.