6.9 Abstrakte Klassen und abstrakte Methoden

Nicht immer soll eine Klasse sofort ausprogrammiert werden. Dies ist der Fall, wenn die Oberklasse lediglich Methoden für die Unterklassen vorgeben möchte, aber nicht weiß, wie sie diese implementieren soll. In Java gibt es dazu zwei Konzepte: abstrakte Klassen und Schnittstellen (engl. interfaces).

6.9.1 Abstrakte Klassen

Bisher haben wir Vererbung eingesetzt, und jede Klasse konnte Objekte bilden. Das ist allerdings nicht immer sinnvoll, nämlich genau dann, wenn eine Klasse nur in einer Vererbungshierarchie existieren soll. Sie kann dann als Modellierungsklasse eine Ist-eine-Art-von-Beziehung ausdrücken und Signaturen für die Unterklassen vorgeben. Eine Oberklasse besitzt dabei Vorgaben für die Unterklasse, das heißt, alle Unterklassen erben die Methoden. Ein Exemplar der Oberklasse selbst muss nicht existieren.

Um dies in Java auszudrücken, setzen wir den Modifizierer abstract an die Typdeklaration der Oberklasse. Von dieser Klasse können dann keine Exemplare gebildet werden, und der Versuch einer Objekterzeugung führt zu einem Compilerfehler. Ansonsten verhalten sich die abstrakten Klassen wie normale, enthalten die gleichen Eigenschaften und können auch selbst von anderen Klassen erben. Abstrakte Klassen sind das Gegenteil von konkreten Klassen.

Wir wollen die Klasse GameObject als Oberklasse für die Spielgegenstände abstrakt machen, da Exemplare davon nicht existieren müssen.

Listing 6.75 com/tutego/insel/game/vh/GameObject.java, GameObject

abstract class GameObject 
{ 
  String name; 
}

Mit dieser abstrakten Klasse GameObject drücken wir aus, dass es eine allgemeine Klasse ist, zu der keine konkreten Objekte existieren. Es gibt in der realen Welt schließlich keine allgemeinen und unspezifizierten Spielgegenstände, sondern nur spezielle Unterarten, zum Beispiel Spieler, Schlüssel, Räume und so weiter. Es ergibt also keinen Sinn, ein Exemplar der Klasse GameObject zu bilden. Die Klasse soll nur in der Hierarchie auftauchen, um alle Spielobjekte zum Typ GameObject zu machen und ihnen einige Eigenschaften zu geben. Dies zeigt, dass Oberklassen allgemeiner gehalten sind und Unterklassen weiter spezialisieren.

Abbildung 6.3 In der UML werden abstrakte Klassennamen kursiv gesetzt.

Die abstrakten Klassen werden normal in der Vererbung eingesetzt. Eine Klasse kann die abstrakte Klasse erweitern und auch selbst wieder abstrakt sein. Problemlos lässt sich wieder Folgendes schreiben:

GameObject   go1 = new Room(); 
GameObject   go2 = new Player(); 
GameObject[] gos = new GameObject[]{ new Player(), new Room() };

6.9.2 Abstrakte Methoden

Der Modifizierer abstract vor dem Schlüsselwort class leitet die Deklaration einer abstrakten Klasse ein. Eine Klasse kann ebenso abstrakt sein wie eine Methode. Eine abstrakte Methode gibt lediglich die Signatur vor, und eine Unterklasse implementiert irgendwann diese Methode. Die Klasse ist somit für den Kopf der Methode zuständig, während die Implementierung an anderer Stelle erfolgt. Abstrakte Methoden drücken aus, dass die Oberklasse keine Ahnung von der Implementierung hat und dass sich die Unterklassen darum kümmern müssen.

Da eine abstrakte Klasse abstrakte Methoden enthalten kann, aber nicht muss, unterscheiden wir:

• Reine (pure) abstrakte Klassen. Die abstrakte Klasse enthält ausschließlich abstrakte Methoden.

• Partiell abstrakte Klassen. Die Klasse ist abstrakt, enthält aber auch konkrete Implementierungen, also nicht abstrakte Methoden. Das bietet den Unterklassen ein Gerüst, was sie nutzen können.

Mit Spielobjekten muss sich spielen lassen

Damit sich mit den Spielobjekten wie Tür, Schlüssel, Raum, Spieler wirklich spielen lässt, sollen die Objekte aufeinander angewendet werden können. Ziel unseres Programms ist es, Sätze abzubilden, die aus Subjekt, Verb, Objekt bestehen:

• Schlüssel öffnet Tür

• Spieler nimmt Bier

• Pinsel kitzelt Spieler

• Radio spielt Musik

Die Programmversion soll etwas einfacher sein und statt unterschiedlicher Aktionen (öffnen, nehmen, ...) nur »nutzen« kennen.

Zur Umsetzung dieser Aufgabe bekommen die Spielklassen wie Schlüssel, Spieler, Pinsel, Radio eine spezielle Funktion, die ein anderes Spielobjekt nehmen und testen, dass sie aufeinander angewendet werden können. Ein Schlüssel öffnet insofern eine Tür, aber keine Musik. Ist die Anwendung möglich, kann die Methode weitere Aktionen ausführen, etwa Zustände setzen. Ob eine Operation möglich war oder nicht, soll eine Rückgabe aussagen. Eine Java-Funktion in GameObject könnte somit folgende Signatur besitzen:

boolean useOn( GameObject object )

Die Operation useOn() soll auf dem eigenen Objekt das an die Methode übergebene Objekt nutzen. Implementiert die Schlüssel-Klasse useOn(), so kann sie testen, ob das GameObject eine Tür ist, und weiterhin prüfen, ob Schlüssel und Tür zusammenpassen. Wenn ja, kann der Schlüssel die Tür öffnen, und die Rückgabe ist true, sonst false.

Da jede Spielobjekt-Klasse die Operation useOn() implementieren muss, soll die Basisklasse sie abstrakt deklarieren, denn eine abstrakte Methode fordert von den Unterklassen eine Implementierung ein, sonst ließen sich keine Exemplare bilden.

Listing 6.76 com/tutego/insel/game/vi/GameObject.java, GameObject

abstract class GameObject 
{ 
  abstract boolean useOn( GameObject object ); 
}

Die Klasse GameObject deklariert eine abstrakte Methode, und da sie immer ohne Implementierung ist, steht ein Semikolon statt des Funktions-Rumpfes. Ist mindestens eine Methode abstrakt, so ist es automatisch die ganze Klasse. Deshalb müssen wir das Schlüsselwort ab-stract ausdrücklich vor den Klassennamen schreiben. Vergessen wir das Schlüsselwort ab-stract bei einer solchen Klasse, erhalten wir einen Compilerfehler. Eine Klasse mit einer abstrakten Methode muss abstrakt sein, da sonst irgendjemand ein Exemplar konstruieren und genau diese Methode aufrufen könnte. Versuchen wir, ein Exemplar einer abstrakten Klasse zu erzeugen, so bekommen wir ebenfalls einen Compilerfehler.

Abbildung 6.4 Auch abstrakte Methoden werden in UML kursiv gesetzt.

Vererben von abstrakten Methoden

Wenn wir von einer Klasse abstrakte Methoden erben, so haben wir zwei Möglichkeiten:

Die Unterklasse Door soll die abstrakte Methode useOn() überschreiben, aber immer false zurückgeben, da sich eine Tür in unserem Szenario auf nichts anwenden lässt. Nach dem Implementieren der abstrakten Methode sind Exemplare von Türen möglich.

Listing 6.77 com/tutego/insel/game/vi/Door.java, Door

public class Door extends GameObject 
{ 
  int     id; 
  boolean isOpen; 
 
  @Override boolean useOn( GameObject object ) 
  { 
    return false; 
  } 
}

Eine Tür hat für den Schlüssel eine ID, denn nicht jeder Schlüssel passt auf jedes Schloss. Weiterhin hat die Tür einen Zustand: sie kann offen oder geschlossen sein.

Die dritte Klasse Key speichert ebenfalls eine ID und implementiert useOn().

Listing 6.78 com/tutego/insel/game/vi/Key.java, Key

public class Key extends GameObject 
{ 
  int id; 
 
  @Override boolean useOn( GameObject object ) 
  { 
    if ( object instanceof Door ) 
      if ( id == ((Door) object).id ) 
        return ((Door) object).isOpen = true; 
 
    return false; 
  } 
}

Die Realisierung ist komplexer. Als Erstes prüft die Methode mit instanceof, ob der Schlüssel auf eine Tür angewendet wird. Wenn ja, muss die ID von Schlüssel und Tür stimmen. Ist auch dieser Vergleich wahr, kann isOpen wahr werden, und die Methode liefert true.

Im Testprogramm gehen zwei Schlüssel eine Tür an. Nur der Schlüssel mit der passenden ID öffnet die Tür. Eine Tür kann nicht auf einen Schlüssel angewendet werden, denn die Funktionen sind nicht symmetrisch ausgelegt.

Listing 6.79 com/tutego/insel/game/vi/Playground.java, main()

Door door = new Door(); 
door.id = 12; 
 
Key  key1 = new Key(); 
key1.id = 99; 
 
Key  key2 = new Key(); 
key2.id = 12; 
 
System.out.printf( "done=%b%n", key1.useOn(door) ); 
System.out.printf( "done=%b, isOpen=%b%n", key2.useOn(door), door.isOpen ); 
System.out.printf( "done=%b%n", door.useOn(key1) );

Die Ausgaben sind:

done=false 
done=true, isOpen=true 
done=false

Ihr Kommentar