7.4    Methoden überschreiben 

Wir haben gesehen, dass eine Unterklasse durch Vererbung die sichtbaren Eigenschaften ihrer Oberklasse erbt. Die Unterklasse kann nun wiederum Methoden hinzufügen. Dabei zählen überladene Methoden – also Methoden, die den gleichen Namen wie eine andere Methode aus einer Oberklasse tragen, aber eine andere Parameteranzahl oder andere Parametertypen haben – zu ganz normalen, hinzugefügten Methoden.

 

7.4.1    Methoden in Unterklassen mit neuem Verhalten ausstatten 

Die Methoden sind das Angebot eines Objekts und die Schnittstelle nach außen. In erster Linie ist das ein Was, aber kein Wie. Unterklassen müssen bedingungslos das Gleiche können wie ihre Oberklasse, allerdings kann das Wie abweichen. In so einem Fall kann die Unterklasse eine Methode der Oberklasse überschreiben. Implementiert die Unterklasse die Methode neu, so sagt sie auf diese Weise: »Ich kann’s besser.« Die überschreibende Methode der Unterklasse kann demnach den Programmcode spezialisieren und Eigenschaften nutzen, die in der Oberklasse nicht bekannt sind. Die überschriebene Methode der Oberklasse ist dann erst einmal aus dem Rennen, und ein Methodenaufruf auf einem Objekt der Unterklasse würde sich in der überschriebenen Methode verfangen.

Damit eine Methode eine andere Methode überschreibt, muss die Unterklasse eine Methode mit dem gleichen Methodennamen und der exakt gleichen Parameterliste (also der gleichen Signatur) besitzen. Der Name der Parametervariablen ist irrelevant. Ist der Rückgabetyp void oder ein primitiver Typ, so muss er in der überschreibenden Methode der gleiche sein. Bei Referenztypen kann der Rückgabetyp etwas variieren, doch das werden wir in Abschnitt 7.8.2, »Kovariante Rückgabetypen«, genauer sehen.

Überschreiben von toString()

Aus der absoluten Basisklasse java.lang.Object bekommen alle Unterklassen eine Methode toString() vererbt, die, meist zu Debug-Zwecken, eine Objektkennung ausgibt:

Listing 7.26     java/lang/Object.java, toString()

public String toString() {

  return getClass().getName() + "@" + Integer.toHexString(hashCode());

}

Die Methode liefert den Namen der Klasse, gefolgt von einem "@" und einer hexadezimalen Kennung. Die Klasse Event ohne eigenes toString() soll die Wirkung testen:

Listing 7.27     src/main/java/com/tutego/insel/game/c/vm/Event.java, Event

class Event {

  String about;

  int    duration;

}

Auf einem Event-Objekt liefert toString() eine etwas kryptische Kennung:

Listing 7.28     src/main/java/com/tutego/insel/game/c/vm/Application.java, Ausschnitt

Event e = new Event();

String s = e.toString();

System.out.println( s ); // com.tutego.insel.game.vm.Event@1a2b3c4d

Es ist also eine gute Idee, toString() in den Unterklassen zu überschreiben. Eine textuelle Objektkennung sollte den Namen der Klasse und die Zustände eines Objekts beinhalten. Für ein Workout, das ein (geerbtes) about und duration sowie selbst caloriesBurned hat, kann dies wie folgt aussehen:

Listing 7.29     src/main/java/com/tutego/insel/game/c/vm/Workout.java, Workout

public class Workout extends Event {

  int caloriesBurned;

 

  @Override public String toString() {

    return String.format( "%s[about=%s, duration=%d, caloriesBurned=%d]",

                          getClass().getSimpleName(),

                          about, duration, caloriesBurned );

  }

}

Den Ausdruck getClass().getSimpleName() übernimmt die Implementierung aus der Klasse Object, und wir bekommen damit dynamisch den Klassennamen, den wir somit nicht fest als String einkodieren müssen. Das ist nützlich, wenn sich einmal der Klassenname ändert.

Abbildung 7.11     »Workout« ist eine Unterklasse von »Event« und hat ein eigenes »toString()«. Ein UML-Stereotyp kennzeichnet die Überschreibung

Und der Test sieht so aus:

Listing 7.30     src/main/java/com/tutego/insel/game/c/vm/Application.java, Ausschnitt

Workout running = new Workout();

running.about = "Joggen";

running.duration = 60;

running.caloriesBurned = 250;

System.out.println( running );

Zur Erinnerung: Ein println(Object) auf einem beliebigen Objekt ruft die toString()-Methode von diesem Objekt auf. Die Ausgabe ist:

Workout[about=Joggen, duration=60, caloriesBurned=250]

Die Annotation @Override

Unsere Beispielklasse Workout nutzt die Annotation @Override an der Methode toString() und macht auf diese Weise deutlich, dass die Klasse eine Methode des Obertyps überschreibt. Die Annotation @Override bedeutet nicht, dass diese Methode in Unterklassen überschrieben werden muss, sondern nur, dass sie selbst eine Methode überschreibt. Annotationen sind zusätzliche Modifizierer, die entweder vom Compiler überprüft werden oder von uns nachträglich abgefragt werden können. Obwohl wir die Annotation @Override nicht nutzen müssen, hat dies zwei Vorteile:

• Zwar weiß die Laufzeitumgebung, dass eine Methode überschrieben wird, allerdings sollte Code dem Leser auch alle Informationen darüber geben, was passiert. Wird eine Methode überschrieben, ist das etwas Bedeutsames, das im Code dokumentiert werden sollte.

• Außerdem überprüft der Compiler, ob wir tatsächlich eine Methode aus der Oberklasse überschreiben. Haben wir uns zum Beispiel im Methodennamen verschrieben und somit der Unterklasse unbeabsichtigt eine neue Methode hinzugefügt, so würde das der Compiler aufgrund seiner Kenntnis von @Override als Fehler melden. Einfache Schreibfehler wie tostring() fallen schnell auf. Überladene Methoden und überschriebene Methoden sind etwas anderes, da eine überladene Methode mit der Ursprungsmethode nur »zufällig« den Namen teilt, aber sonst keinen Bezug zur Logik hat. Und so hilft @Override, dass Entwickler wirklich Methoden überschreiben und nicht aus Versehen Methoden mit falschen Parametern überladen.

Finale Parameter in der Vererbung *

Wird eine Methode überschrieben, dann sind die Typen der Parameterliste bestimmend, nicht die Namen. Auch spielt es keine Rolle, ob die Parametervariablen final sind oder nicht. Wir können es als zusätzliche Information für die jeweilige Methode betrachten. Eine Unterklasse kann demnach beliebig das final hinzufügen oder auch wegnehmen. Alte Bibliotheken lassen sich so leicht weiterverwenden.

 

7.4.2    Mit super an die Eltern 

Wenn wir eine Methode überschreiben, dann entscheiden wir uns für eine gänzlich neue Implementierung. Was ist aber, wenn die Funktionalität im Großen und Ganzen gut war und nur eine Kleinigkeit fehlte? Im Fall der überschriebenen toString()-Methode realisiert die Unterklasse eine völlig neue Implementierung und bezieht sich dabei nicht auf die Logik der Oberklasse.

Möchte eine Unterklasse sagen: »Was meine Eltern können, ist doch gar nicht so schlecht«, kann mit der speziellen Referenz super auf die Eigenschaften im Namensraum der Oberklasse zugegriffen werden. (Natürlich ist das Objekt hinter super und this das gleiche, nur der Namensraum ist ein anderer.) Auf diese Weise können Unterklassen immer noch etwas Eigenes machen, aber die Realisierung aus der Elternklasse ist weiterhin verfügbar.

In unserem Spiel hatte Event kein toString(). Ändern wir dies:

Listing 7.31     src/main/java/com/tutego/insel/game/c/vn/Event.java, Event

class Event {

  String about;

  int    duration;

 

  @Override public String toString() {

    return String.format( "%s[about=%s, duration=%d]",

                          getClass().getSimpleName(),

                          about, duration );

  }

}

Die Unterklasse Workout erweitert Event und sollte toString() neu realisieren, da ein Workout eine zusätzliche Objektvariable hat, nämlich caloriesBurned. Wird toString() allerdings in Workout überschrieben, muss sich toString() auch um die geerbten Eigenschaften kümmern, sprich: um about und duration. Das ist ungünstig, denn kommt etwa in der Oberklasse Event eine Objektvariable hinzu oder wird gelöscht, müssen alle toString()-Methoden von allen Unterklassen geändert werden, wenn die Unterklassen alle Belegungen der Objektvariablen mit in die String-Kennung einbinden möchten. Das ist ungünstig. Allgemein gesprochen: Eine Unterklasse sollte keine Verantwortung für die Oberklasse übernehmen.

Eine Lösung für das Problem ist, in toString() einer Unterklasse wie Workout einfach auf die toString()-Methode der Oberklasse Event zuzugreifen und dann die möglichen Zustände vom Basistyp mit aufzunehmen:

Listing 7.32     src/main/java/com/tutego/insel/game/c/vn/Event.java, Ausschnitt

public class Workout extends Event {

  int caloriesBurned;

 

  @Override public String toString() {

    return String.format( "%s[caloriesBurned=%d]",

                          super.toString(),

                          caloriesBurned );

  }

}

Stünde statt super.toString() nur toString() im Rumpf, würde der Methodenaufruf in die Endlosrekursion führen. Daher funktioniert es ohne super-Referenz nicht.

Ein Test zeigt das Resultat:

Listing 7.33     src/main/java/com/tutego/insel/game/c/vn/Application.java, Ausschnitt

Workout running = new Workout();

running.about = "Joggen";

running.duration = 60;

running.caloriesBurned = 250;

System.out.println( running );

Die Ausgabe ist:

Workout[about=Joggen, duration=60][caloriesBurned=250]

Eigenschaften der super-Referenz *

Nicht nur in überschriebenen Methoden kann die super-Referenz sinnvoll eingesetzt werden: Sie ist auch interessant, wenn Methoden der Oberklasse aufgerufen werden sollen und nicht eigene überschriebene. So macht das folgende Beispiel klar, dass auf jeden Fall toString() der Oberklasse Object aufgerufen werden soll und nicht die eigene überschriebene Variante:

Listing 7.34     src/main/java/com/tutego/insel/oop/ToStringFromSuper.java

public class ToStringFromSuper {



  public ToStringFromSuper() {

    System.out.println( super.toString() );  // Aufruf von Object toString()

  }



  @Override

  public String toString() {

    return "Nein";

  }



  public static void main( String[] args ) {

    new ToStringFromSuper();       // ToStringFromSuper@3e25a5

  }

}

Natürlich kann super nur dann eingesetzt werden, wenn in der Oberklasse die Methode eine gültige Sichtbarkeit hat. Es ist also nicht möglich, mit diesem Konstrukt das Geheimnisprinzip zu durchbrechen.

Eine Aneinanderreihung von super-Schlüsselwörtern bei einer tieferen Vererbungshierarchie ist nicht möglich. Hinter einem super muss eine Objekteigenschaft stehen; sie gilt also für eine überschriebene Methode oder eine überdeckte Objektvariable. Anweisungen wie super. super.lol() sind somit immer ungültig. Eine Unterklasse empfängt alle Eigenschaften ihrer Oberklassen als Einheit und unterscheidet nicht, aus welcher Hierarchie etwas kommt.