6.10 Die Oberklasse gibt Funktionalität vor

Der Vorteil beim Überschreiben ist also, dass die Oberklasse eine einfache Implementierung vorgibt, die die Unterklasse dann spezialisieren kann. Doch nicht nur die Spezialisierung ist aus der Sicht des Designs interessant, sondern auch die Bedeutung der Vererbung. Bei der Vererbung haben wir eine Form der Ist-eine-Beziehung oder Ist-eine-Art-von-Beziehung. Wenn nun eine Oberklasse eine Methode anbietet, die die Unterklassen überschreibt, so wissen wir, dass alle Unterklassen diese Methode haben müssen. Wir werden gleich sehen, dass dies zu einem der wichtigsten Konstrukte in objektorientierten Programmiersprachen führt.

Modifizieren wir dazu unsere Gebäude- und Diskotheken-Klasse ein wenig. Zusätzlich wollen wir als Unterklasse von Gebaeude eine neue Klasse einführen, die parallel zur Disko steht: eine Kirche. Zunächst führen wir in der Klasse Gebaeude die Methode getId() ein. Die Idee ist, dass sich später die Objekte über eine ID identifizieren lassen sollen.

Listing 6.38 va/Gebaeude.java

package va;
public class Gebaeude
{
  public final static int UNDEFINIERT  = 0;
  public final static int DISKO        = 1;
  public final static int KIRCHE       = 2;
  /**
   * Liefert den Typ des konkreten Gebäudes.
   * 
   * @return Gebäudetyp.
   */ 
  public int getId()
  {
   return UNDEFINIERT; 
  }
}

Vielleicht ist an dieser Stelle noch nicht ganz klar, wieso wir die Methode getId() hier einführen, gäbe es doch auch die Möglichkeit, die Funktion getId() in Disko und in Kirche einzusetzen. Das ist zwar richtig, aber die Klassen hätten dann nur rein »zufällig« eine Methode mit dem Namen getId(). Es gäbe keine Gemeinsamkeit, und daher nehmen wie die Modellierung über die Oberklasse vor. Wie schaffen somit eine Gemeinsamkeit, da Disko und Kirche nun automatisch eine Methode getId() haben.

Hier klicken, um das Bild zu Vergrößern

Die Implementierung von Disko und Kirche überschreiben die geerbte Implementierung aus der Oberklasse Gebaeude. Im Quellcode sieht das dann so aus:

Listing 6.39 va/Kirche.java

package va;
public class Kirche extends Gebaeude
{
  private int anzahlBeichtstühle;
  public int getId()
  {
    return KIRCHE;
  }
}

Listing 6.40 va/Disko.java

package va;
public class Disko extends Gebaeude
{
  public int getId()
  {
    return DISKO;
  }
}

Es fehlen noch ein paar kleine Testzeilen:

Disko  d = new Disko();
Kirche k = new Kirche();
System.out.println( "Id Kirche:" + d.getId() +   // Id Kirche:1
                    " Id Disko: " + k.getId() ); // Id Disko: 2

Die angegebenen Zeilen sind leicht zu verstehen. Die Laufzeitumgebung sucht nun von unten nach oben in der Vererbungshierarchie nach der Methode getId() und findet sie sofort in Kirche beziehungsweise Disko. Würden wir eine neue Unterklasse von Gebaeude schaffen und getId() nicht überschreiben, so würde die Laufzeitumgebung getId() in Gebaeude finden und 0 liefern.

6.10.1 Dynamisches Binden als Beispiel für Polymorphie

Verbinden wir unser Wissen über vererbte Methoden und die Verträglichkeit von Referenztypen zu folgendem Beispiel:

Gebaeude e = new Disko();
Gebaeude l = new Kirche();

Dies geht auf jeden Fall in Ordnung, da Disko und Kirche ##Unterklassen von Gebaeude sind. e und l verzichten auf die möglicherweise hinzugefügten Attribute der Unterklassen.

Aber wirklich interessant ist die Feststellung, dass Gebaeude ja die Methode getId() besitzt, die wir aufrufen können:

System.out.println( e.getId() );
System.out.println( l.getId() );

Jetzt ist die spannendste Frage in der gesamten Objektorientierung Folgende: Was passiert bei dem Methodenaufruf? Es gibt zwei Möglichkeiten.

Diese zweite Lösung ist richtig. Da hier aus dem statisch im Programmtext vereinbarten Typ der Variablen nicht abzulesen ist, welche Implementierung der Methode getId() aufgerufen wird, sprechen wir von dynamischer Bindung. Erst zur Laufzeit wird dynamisch die entsprechende Objektmethode, passend zum tatsächlichen Typ des aufrufenden Objekts, ausgewählt. Die dynamische Bindung ist eine Anwendung von Polymorphie. Obwohl Polymorphie mehr ist als dynamisches Binden, wollen wir beide Begriffe synonym verwenden.

Werfen wir einen Blick auf ein Programm, welches dynamisches Binden noch deutlicher macht.

Listing 6.41 va/Stadt.java

package va;
public class Stadt
{
  public static void main( String args[] )
  {
    Gebaeude gebaeude[] = { new Disko(), new Kirche(), new Kirche() };
    kennungenAusgeben( gebaeude );  // 1 2 2
  }

Wir erzeugen drei konkrete Gebäude, die wir in ein Feld legen. Anschließend übergeben wir der Methode kennungenAusgeben() das Feld mit den Objekten:

  static void kennungenAusgeben( Gebaeude g[] )
  {
    for ( int i = 0; i < g.length; i++ )
      System.out.println( g[i].getId() ); // Hier ist die Polymorphie
  }
}

Spätestens hier ist der Compiler mit dem Wissen über die Objekte im Array am Ende, da er nun wirklich bei der Methode kennungAusgeben() nicht weiß, welche Objekte ihn als Array-Elemente erwarten.

6.10.2 Keine Polymorphie bei privaten, statischen und finalen Methoden

Obwohl Methodenaufrufe in Java in der Regel polymorph gebunden sind, gibt es bei privaten, statischen und finalen Methoden eine Ausnahme; sie können nicht überschrieben werden und sind daher auch nicht polymorph gebunden. Wir wollen uns das an einer privaten Funktion ansehen.

Listing 6.42 NoPolyWithPrivate.java

class NoPolyWithPrivate
{
  public static void main( String args[] )
  {
    Unter unsicht = new Unter();
    System.out.println( unsicht.bar() );   // 2
  }
}
class Ober
{
  private int furcht()
  {
    return 2;
  }
  int bar()
  {
    return furcht();
  }
}
class Unter extends Ober
{
  int furcht()
  {
    return 1;
  }
}

Der Compiler meldet beim Überschreiben der Funktion furcht() keinen Fehler. Für den Compiler ist es in Ordnung, wenn es eine Methode in der Unterklasse gibt, die den gleichen Namen wie eine private Methode in der Oberklasse trägt. Das ist auch gut so, denn private Implementierungen sind ja sowieso geheim und versteckt. Die Unterklasse soll von den privaten Methoden in der Oberklasse gar nichts wissen.

Die Laufzeitumgebung macht etwas Erstaunliches für unsicht.bar(). Die Funktion bar() wird aus der Oberklasse geerbt. Normalerweise wissen wir, dass Funktionen, die in bar() aufgerufen werden, dynamisch gebunden werden, das heißt, dass wir eigentlich bei furcht() in Unter laden müssten, da wir ein Objekt vom Typ Unter haben. Bei privaten Methoden ist das aber anders. Wenn eine aufgerufene Methode den Modifizierer private trägt, dann wird nicht dynamisch gebunden. Das ist ein wichtiger Beitrag zur Sicherheit. Falls nämlich Unterklassen interne private Methoden überschreiben könnten, wäre dies eine Verletzung der inneren Arbeitsweise der Oberklasse. In einem Satz: Private Methoden sind nicht in den Unterklassen sichtbar und werden daher nicht verdeckt oder überschrieben. Andernfalls könnten private Implementierungen im Nachhinein geändert werden und Oberklassen wären nicht mehr sicher davor, dass tatsächlich ihre eigenen Funktionen benutzt werden.

Casten wir in der Methode bar() in der Klasse Ober über die this-Referenz auf ein Objekt vom Typ Unter, dann wird ausdrücklich diese Methode aufgerufen, was jedoch kein typisches objektorientiertes Konstrukt darstellt. bar() in der Klasse Ober ist damit nicht mehr für Ober-Objekte benutzbar.

int bar()
{
  return ((Unter)(this)).furcht();
}

6.10.3 Polymorphie bei Konstruktoraufrufen

Dass ein Konstruktor der Unterklasse zuerst den Konstruktor der Oberklasse aufruft, kann die Initialisierung der Variablen in der Unterklasse anfällig stören. Schauen wir uns erst Folgendes an:

class Rausschmeisser extends Mukkityp
{
  String was = "Ich bin ein Rausschmeisser";
}

Wo wird nun die Variable was initialisiert? Wir wissen, dass die Initialisierungen immer im Konstruktor vorgenommen werden, aber da gibt es ja noch gleichzeitig ein super() im Konstruktor. Da die Sprachdefinition Anweisungen vor super() verbietet, muss also die Zuweisung hinter dem Aufruf der Oberklasse folgen. Das Problem ist nun, dass ein Konstruktor der Oberklasse früher aufgerufen wurde als Variablen in der Unterklasse initialisiert wurden. Wenn es die Oberklasse nun schafft, auf die Variablen der Unterklasse zuzugreifen, so wird der erst später gesetzte Wert fehlen. Der Zugriff gelingt tatsächlich, doch nur durch einen Trick, da eine Oberklasse (etwa Mukkityp) nicht auf die Variablen der Unterklasse zugreifen kann. Aber wir können in der Oberklasse eine Methode der Unterklasse aufrufen, nämlich genau die, die die Unterklasse aus der Oberklasse überschreibt. Da Methodenaufrufe dynamisch gebunden werden, kann eine Methode den Wert auslesen.

Listing 6.43 Rausschmeisser.java

class Mukkityp
{
  Mukkityp()
  {
    wasBinIch();
  }
  void wasBinIch()
  {
    System.out.println( "Ich weiß es noch nicht :-(" );
  }
}
public class Rausschmeisser extends Mukkityp
{
  String was = "Ich bin ein Rausschmeisser";
  
  void wasBinIch()
  {
    System.out.println( was );
  }
  public static void main( String args[] )
  {
    Mukkityp bb = new Mukkityp();
    bb.wasBinIch();
    Rausschmeisser bouncer = new Rausschmeisser();
    bouncer.wasBinIch();
  }
}

Die Ausgabe ist nun Folgende:

Ich weiß es noch nicht :-(
Ich weiß es noch nicht :-(
null
Ich bin ein Rausschmeisser

Das Besondere bei diesem Programm ist, dass überschriebene Methoden - hier wasBinIch() - dynamisch gebunden werden. Diese Bindung gibt es auch dann schon, wenn das Objekt noch nicht vollständig initialisiert wurde. Daher ruft der Konstruktor der Oberklasse Mukkityp nicht wasBinIch() von Mukkityp auf, sondern wasBinIch() von Rausschmeisser. Wenn in diesem Beispiel ein Rausschmeisser-Objekt erzeugt wird, dann ruft Rausschmeisser mit super() den Konstruktor von Mukkityp auf. Dieser ruft wiederum die Methode wasBinIch() in Rausschmeisser auf, und er findet dort keinen String, da dieser erst nach super() gesetzt wird. Schreiben wir den Konstruktor von Rausschmeisser einmal ausdrücklich hin:

public class Rausschmeisser extends Mukkityp
{
  String was;
  Rausschmeisser()
  {
    super();
    was = "Ich bin ein Rausschmeisser";
  }
}

Die Konsequenz, die sich daraus ergibt, ist Folgende: Dynamisch gebundene Methodenaufrufe über die this-Referenz sind in Konstruktoren potenziell gefährlich und sollten deshalb vermieden werden. Vermeiden lässt sich das, in dem der Konstruktor nur private Methoden aufruft, denn diese werden nicht dynamisch gebunden. Wenn der Konstruktor eine private Methode in seiner Klasse aufruft, dann bleibt es auch dabei.