Der Aufruf von polymorphen Methoden während der Initialisierungsphase eines Objekts kann zu Überraschungen führen. Deshalb gibt es die Regel: „Man soll keine non-final Methoden im Konstruktor aufrufen.“  In diesem Artikel wollen wir uns ansehen, warum diese Regel sinnvoll ist und wie genau die Initialisierung von Objekten in Java funktioniert.
 
 

Ein problematisches Beispiel

public class StaffMember {
    private Person person;
    private long salary;
    private OrgUnit department;

    public StaffMember(Person p, long s, OrgUnit o) {
      person = p;
      salary = s;
      department = o;
      o.addMember(this);
    }
    public long getCompensation() {
      return salary;
    }
}
public class BoardMember extends StaffMember {
    private long bonus;

    public BoardMember(Person p, long s,long b, OrgUnit o) {
    super(p,s,o);
    bonus = b;
    }
    public long getCompensation() {
       return super.getCompensation()+bonus;
    }
}

Neben den hier gezeigten Klassen gibt es ein Klasse OrgUnit, welche die Abteilungen der Firma repräsentiert. Was diese Klasse genau tut, ist hier unerheblich.  Wichtig ist in unserem Zusammenhang nur, daß jeder Mitarbeiter bei seiner Organisationseinheit registriert wird.  Das geschieht im Konstruktor der Klasse StaffMember über die Methode OrgUnit.addMember(). Hier eine verkürzte Form dieser Klasse OrgUnit:

public class OrgUnit {
 private String name;
 private Set members = new TreeSet();
 private long cost;

 public final void addMember(StaffMember m) {
  members.add(m);
  cost += m.getCompensation();
 }
}

Nun ergibt sich folgender Effekt: wenn man Angestellte und Vorstandsmitglieder konstruiert und den verschiedenen Organisationseinheiten zuordnet, wird man feststellen, daß etwas mit den Gehaltsberechnungen nicht stimmt.  Hier ein Testprogramm:

public final class Corporation {
 private Set units = new HashSet();

 public Corporation()  {
  OrgUnit dep = new OrgUnit("Development");
  units.add(dep);
  new StaffMember(new Person("Helmut", "Hunter"),3000000,dep);
  new StaffMember(new Person("Lorrie", "Lindon"),3000000,dep);
  new StaffMember(new Person("Jeremy", "Jordan"),4000000,dep);

  dep = new OrgUnit("Board");
  units.add(dep);
  new BoardMember(new Person("Vito", "Voracious"),100000000,500000,dep);
  new BoardMember(new Person("Mona", "Malicious"),100000000,300000,dep);
 }
 public static void main(String[] args) {
    Corporation corp = new Corporation();
    System.out.println(corp);
 }
}

Hier die Ausgabe, die das Testprogramm produziert, unter der Annahme, daß entsprechende toString()-Methoden implementiert wurden:

corporation.OrgUnit:
name: Development
cost: 100000 USD
 Helmut Hunter ( Development ) [ 30000 USD ] ID: #28904249
 Jeremy Jordan ( Development ) [ 40000 USD ] ID: #26208195
 Lorrie Lindon ( Development ) [ 30000 USD ] ID: #12115735

corporation. OrgUnit:
name: Board
cost: 2000000 USD
 Mona Malicious ( Board ) [ 1003000 USD ] ID: #20876681
 Vito Voracious ( Board ) [ 1005000 USD ] ID: #29240677

Die Vorstandsmitglieder bekommen zwar ihren Gehaltsbonus, aber in den Gesamtkosten der Organisationseinheit ist offenbar nur das Grundgehalt berücksichtigt.  Wie kann das passieren?
 

Problemanalyse

Damit sind ohne jeden Zweifel beim Verlassen des BoardMember-Konstruktors alle Felder des BoardMember-Objekts korrekt initialisiert. Die Methode getCompensation() der Klasse BoardMember wird korrekt das Gehalt inklusive Bonus berechnen. Warum stimmen dann die Gesamtkosten der Organisationseinheit nicht?  Dort wurde doch auch die Methode getCompensation() der Klasse BoardMember aufgerufen.

Das Problem liegt darin, daß die Methode getCompensation() während der Konstruktion des BoardMember-Objekts aufgerufen wird, und zwar zu einem Zeitpunkt, zu dem das BoardMember-Objekt noch gar nicht fertig ist.  Ein Teil des Objekts, nämlich das Bonus-Feld, ist zu jenem Zeitpunkt noch nicht initialisiert und hat noch immer den Wert 0. Die Methode getCompensation() greift auf das noch nicht initialisierte Bonus-Feld zu und berechnet das Gehalt folgerichtig mit Bonus 0.

Um das nachzuvollziehen sehen wir uns einmal im Detail an, wie Objekte in Java konstruiert werden.
 

Objektkonstruktion in Java

1. Speicherbeschaffung. Das Laufzeitsystem beschafft Speicher in der richtigen Menge, d.h. soviel Speicher, wie für die Felder des Objekts gebraucht wird.  Der Speicher ist zunächst einmal völlig uninitialisiert und die Felder haben zufällige Inhalte.
2. Defaultinitialisierung.  Das Laufzeitsystem initialisiert den beschafften Speicher mit vordefinierten Initialwerten, d.h. alle Felder des Objekts werden mit Defaultwerten belegt.  Die Initialwerte sind abhängig von Typ der Felder und können der Tabelle „Defaultwerte“ entnommen werden.
3. Superklassenkonstruktor. Ein Konstruktor der Superklasse wird gerufen. Das ist entweder implizit der Defaultkonstruktor oder explizit ein Konstruktor mit Argumenten, der über super(…) angestoßen wird. Hier geht eine Rekursion los, die sukzessive alle Superklassenkonstruktoren bis hinauf zu Object aufruft.  Danach sind alle geerbten Felder initialisiert.
4. Explizite Initialisierung. Alle Felder, die in der betreffenden Klasse definiert sind und für es eine Initialisierung gibt, bekommen ihre expliziten Initialwerte zugewiesen. Danach sind alle Felder (die geerbten und die eigenen Felder) initialisiert.
5. Konstruktor-Body. Die eigentlichen Anweisungen des Konstruktors werden ausgeführt.

 

Type	Default Value
byte	(byte) 0
short	(short) 0
int	0
long	0L
float	0.0f
double	0.0d
char	'\u0000'
boolean	false
reference	null

Tabelle 1: Defaultwert

• Alternativer Konstruktor. In Phase (3) kann anstelle des Superklassenkonstruktors auch ein anderer Konstruktor derselben Klasse über this(…) aufgerufen werden.  Dieser alternative Konstruktor führt dann seinerseits noch einmal eine Phase (3) durch, d.h. er ruft einen Superklassenkonstruktor oder einen weiteren alternativen Konstruktor derselben Klasse auf. Nach der Phase (3), d.h. wenn all Superklassenkonstruktoren bis hinauf zum Konstruktor von Object ausgeführt worden sind, erfolgt in Phase (4) die explizite Initialisierung der Felder der Klasse und in Phase (5) die Ausführung der Anweisungen im Konstruktor-Body. Damit ist der alternative Konstruktor mit seiner Arbeit fertig und der Kontrollfluß kehrt zum ursprünglichen Konstruktor zurück.  Im ursprünglichen Konstruktor geht es nun nicht mit Phase (4), sondern mit Phase (5) weiter, weil Phase (4),  die explizite Initialisierung der Felder der Klasse, bereits im alternativen Konstruktor erledigt wurde.
• Instance Initializer. Alle Initialisierungen in Phase (4) werden in der Reihenfolge gemacht, in der sie in der Klassendefinition auftauchen. Dabei werden nicht nur die expliziten Initialisierungen der Felder vorgenommen (die sogenannten „instance variable initializer“), sondern es werden auch die relativ ungebräuchlichen „instance initializer“ ausgeführt (siehe / JLS / §8.8.5.1).  Instance Initializer werden eigentlich nur in anonymen inneren Klassen verwendet, weil anonyme Klassen keinen Namen haben und man deshalb keinen Konstruktor für eine anonyme Klasse schreiben kann. Anstelle eines Defaultkonstruktors schreibt man für eine anonyme Klasse einen Instance Initializer, falls einer benötigt wird.

class Elem2D {
  private int x = -1;
  private int y;
  public Elem2D() { y = 1; }
}

class ColoredElem2D extends Elem2D {
  private int color = 0xFF00FF;
}

...
ColoredElem2D elem = new ColoredElem2D();
...

Wenn ein Objekt vom Subtyp ColoredElem2D erzeugt wird, dann erfolgt die Konstruktion in folgenden Schritten:

• Speicherbeschaffung für alle 3 Felder der Klasse ColoredElem2D sowie für alle von Object geerbten Felder
• Defaultinitialisierung aller Felder mit 0
• Aufruf des Defaultkonstruktors von ColoredElem2D
• Aufruf von super(), d.h. des Defaultkonstruktors von Elem2D
• Aufruf von super(), d.h. des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Object
• Konstruktor-Body des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Elem2D , d.h. hier wird x  mit -1 initialisiert
• Konstruktor-Body des Defaultkonstruktors von Elem2D, d.h. hier wird y mit 1 initialisiert
• Explizite Initialisierung der Felder von ColoredElem2D, d.h. hier wird color initialisiert
• Konstruktor-Body des Defaultkonstruktors von ColoredElem2D; ist in diesem Falle leer

class Elem3D {
  private int x;
  private int y;
  private int z = 3; // instance variable initializer
  { x = z; }    // instance initializer
  public Elem3D()
  { y = (x+z)*2}         // constructor body
}

class ColoredElem3D extends Elem3D {
  private int color;

  ColoredElem3D(int x, int y, int z, int col) {
    super(x,y,z);
    color = col ;
  }
  ColoredElem3D() {
    this(x,y,z,0xFF00FF);
  }
}

...
ColoredElem3D elem = new ColoredElem3D();
...

Wenn ein Objekt vom Subtyp ColoredElem3D erzeugt wird, dann erfolgt die Konstruktion in folgenden Schritten:

• Speicherbeschaffung für alle 4 Felder der Klasse ColoredElem3D sowie für alle von Object geerbten Felder
• Defaultinitialisierung aller Felder mit 0
• Aufruf des Defaultkonstruktors von ColoredElem3D
• Aufruf von this(...), d.h. eines alternativen Konstruktors von ColoredElem3D
• Aufruf von super(...), d.h. eines Konstruktors von Elem3D
• Aufruf von super(), d.h. des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Object
• Konstruktor-Body des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Elem3D

Es wird zuerst z mit 3 initialisiert, so wie im Initialisierungsausdruck angegeben. Dann wird der Instance Initializer ausgeführt; dabei wird x mit dem Inhalt von z initialisiert.
• Konstruktor-Body des Defaultkonstruktors von Elem3D, d.h. hier wird y initialisiert
• Explizite Initialisierung der Felder von ColoredElem3D; in diesem Falle ist nichts zu tun
• Konstruktor-Body des alternativen Konstruktors von ColoredElem3D, hier wird color initialisiert
• Konstruktor-Body des Defaultkonstruktors von ColoredElem3D; ist in diesem Falle leer

Kehren wir zu unserem Ausgangspunkt zurück. Unser Problem in  der Fallstudie stammt vom Aufruf einer polymorphen Methode während der Konstruktion.  Sehen wir uns also an, wie polymorphe Methoden im Konstruktionsprozeß behandelt werden.
 

Aufruf polymorpher Methoden während der Konstruktion

Der Superklassenkonstruktor wird aber nicht nur für die Konstruktion von Superklassenobjekten verwendet, sondern wird auch während der Konstruktion von Subklassenobjekten aufgerufen. Wenn man sich die Abfolge der Aktionen während der Konstruktion eines Subklassenobjekts noch einmal anschaut, dann stellt man fest, daß entweder explizit über super(...) oder implizit vom Compiler ein Konstruktor der Superklasse angestoßen wird. Dann ergibt sich eine interessante Situation, wenn dieser Superklassenkonstruktor eine redefinierte Methode aufruft: dem Compiler stehen für den Aufruf sowohl die Variante der Methode aus der Superklasse als auch die Variante der Methode aus der Subklasse zur Verfügung.  Er entscheidet, welche der beiden Methoden gerufen wird, abhängig vom Typ des Objekts, auf dem die Methode angestoßen wird.  Während der Konstruktion eines Subklassenobjekts wird er also die Subklassenvariante der redefinierten Methode aufrufen. Die Subklassenvariante greift unter Umständen auf subklassenspezifische Felder zu. Nun ist die Frage: in welchem Zustand sind diese Subklassenfelder zum Zeitpunkt des Aufrufs? Schließlich befinden wird uns gerade mitten im Prozeß der Initialisierung des Subklassenobjekts. Sind alle Felder schon ordnungsgemäß initialisiert, wenn die Subklassenvariante der Methode gerufen wird, oder nicht? Oder läßt sich das vielleicht gar nicht vorhersagen?

Ob die möglicherweise benutzen Felder des Subklassenobjekts bereits ordnungsgemäß initialisiert sind, hängt davon ab, zu welchem Zeitpunkt während der Konstruktion die fragliche Methode aufgerufen wird. Sehen wir uns an, was da genau passiert. Betrachten wir dazu ein einfaches Beispiel:

class Elem2D {
  private int x = -1;
  private int y;
  public Elem2D() { y = calculateY(); }
  protected int calculateY() { return 2*(x+1) ; }
}

class Elem3D extends Elem2D {
  private int z = 1;
  protected int calculateY() { return 2*(x+z); }
}

...
Elem3D elem = new Elem3D();
...

Wenn ein Objekt vom Subtyp Elem3D erzeugt wird, dann erfolgt die Konstruktion wie bereits zuvor erläutert in folgenden Schritten:

• Speicherbeschaffung für alle Felder
• Defaultinitialisierung aller Felder mit 0
• Aufruf des Defaultkonstruktors von Elem3D
• Aufruf von super(), d.h. des Defaultkonstruktors von Elem2D
• Aufruf von super(), d.h. des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Object
• Konstruktor-Body des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Elem2D , d.h. hier wird x  mit -1 initialisiert
• Konstruktor-Body des Defaultkonstruktors von Elem2D, d.h. hier wird y mit dem Ergebnis von  calculateY() initialisiert
• Explizite Initialisierung der Felder von Elem3D, d.h. hier wird z mit 1 initialisiert
• Konstruktor-Body des Defaultkonstruktors von Elem3D; ist in diesem Falle leer

Die Überraschung rührt daher, daß die Verwendung von halbfertigen Objekten nicht den Konventionen der Objektorientierung entspricht. Die Grundidee in der Objektorientierung ist eigentlich, daß jede Methode eines Objekts das Objekt von einem konsistenten Zustand in einen anderen konsistenten Zustand überführt.  Der Konstruktor hat dabei die besondere Aufgabe, den ersten konsistenten Zustand herzustellen. Alle Methode, außer dem Konstruktor, können immer davon ausgehen, daß sie auf einem konsistenten Objekt aufgerufen werden. Das genau ist aber in unserem Beispiel nicht der Fall.  Die Methode calculateY() der Klasse Elem2D wird auf einem inkonsistenten, halbfertigen Objekt aufgerufen. Darauf ist die Methode nicht vorbereitet und das Ergebnis dürfte überraschend oder gar fehlerhaft, sein.  Was kann man in solchen Fällen tun?

Theoretisch könnte man die fragliche Methode darauf vorbereiten, mit inkonsistenten Objekte fertig zu werden.  Das macht aber nur in seltenen Ausnahmefällen Sinn.  Bestenfalls könnte man eine Konsistenzprüfung machen und eine Exception werfen, wenn das Objekt inkonsistent ist. Das hätte aber zur Folge, daß jede Konstruktion von Subklassenobjekten grundsätzlich fehlschlägt. Keine gute Idee.

Aus diesen Überlegungen ergibt sich die Empfehlung, die in vielen Büchern zu finden ist (siehe / VER /, / HAG /, / BLO /):

Man soll niemals überschreibbare Methoden in einem Konstruktor aufrufen .

Zurück zum problematischen Beispiel

public class StaffMember {
    private Person person = null;
    private long salary = 0;
    private OrgUnit department = null;

    public StaffMember(Person p, long s, OrgUnit o) {
      person = p;
      salary = s;
      department = o;
      o.addMember(this);
    }
    public long getCompensation() {
      return salary;
    }
}
public class BoardMember extends StaffMember {
    private long bonus = 0;

    public BoardMember(Person p, long s,long b, OrgUnit o) {
    super(p,s,o);
    bonus = b;
    }
    public long getCompensation() {
       return super.getCompensation()+bonus;
    }
}

Wenn ein Objekt vom Subtyp BoardMember erzeugt wird, dann erfolgt die Konstruktion wie bereits zuvor erläutert in folgenden Schritten:

• Speicherbeschaffung für alle Felder
• Defaultinitialisierung aller Felder mit 0 bzw. null
• Aufruf des Konstruktors von BoardMember
• Aufruf von super(...), d.h. eines Konstruktors von StaffMember
• Aufruf von super(), d.h. des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von Object
• Konstruktor-Body des Defaultkonstruktors von Object
• Explizite Initialisierung der Felder von StaffMember; entfällt in diesem Fall
• Konstruktor-Body des Konstruktors von StaffMember, d.h. hier werden person, salary und department  mit ihren eigentlichen Initialwerten initialisiert und es wird die Methode OrgUnit.addMember() gerufen
• Explizite Initialisierung der Felder von BoardMember; entfällt in diesem Fall
• Konstruktor-Body des Defaultkonstruktors von BoardMember; hier wird bonus mit seinem eigentlichen Initialwert initialisiert

public class OrgUnit {
 private String name;
 private Set members = new TreeSet();
 private long cost;

 public final void addMember(StaffMember m) {
  members.add(m);
  cost += m.getCompensation();
 }
}

Das Problem kommt daher, daß die Regel „Man soll niemals überschreibbare Methoden in einem Konstruktor aufrufen.“ etwas verkürzt ist. Eigentlich müßte es heißen: „Man soll niemals überschreibbare Methoden der eigenen Klasse in einem Konstruktor aufrufen – auch nicht indirekt.“ In unserer Fallstudie haben wird die this-Referenz als Argument an eine Methode einer anderen Klasse übergeben, die die this-Referenz verwendet hat, um eine überschreibbare Methode unserer Klasse aufzurufen. Wir haben also auf Umwegen eine überschreibbare Methode unserer eigenen Klasse während der Konstruktion aufgerufen, und das führt dann zu Problemen.

Außerdem gibt die Methode getCompensation() die this-Referenz an die Methode TreeSet.add() weiter.  Was macht die add()-Methode der TreeSet-Klasse eigentlich mit unserem unfertigen Objekt?  Sie wird die compareTo()-Methode unserer Subklasse rufen, die wiederum das noch nicht initialisierte Bonus-Feld für den Vergleich heranziehen wird, und auch das wird zu Fehlern führen, die vielleicht nicht sofort, sondern erst irgendwann später auffallen werden.

Was macht man also, wenn man eine solche problematische Situation entdeckt hat? Leider gibt es meistens keine einfache Lösung, die ohne ein Redesign der Klassenhierarchie und der an der Konstruktion beteiligten Methoden auskäme. Es empfiehlt sich also, bereits beim Design einer non-final-Klasse darauf zu achten, daß keine überschreibbaren Methoden der eigenen Klasse direkt oder indirekt aus dem Konstruktor heraus aufgerufen werden.  Wenn man in Versuchung ist, es dennoch zu tun, dann sollte man sein  Design sofort noch einmal überdenken.

Nun ist die Weitergabe der this-Referenz während der Konstruktion durchaus gängige Praxis, typischerweise im Zusammenhang mit Registrierungen, die während der Konstruktion durchgeführt werden.  In dynamischen System kommt es häufiger vor, daß sich Objekte während der Konstruktion bei einer anderen logischen Einheit im System anmelden, damit sie später unter bestimmten Umständen zurückgerufen werden; das bezeichnet man als Callback-Registrierung. Dabei wird, wie in unserem Beispiel, die this-Referenz auf ein noch unfertiges Objekt zur Registrierung weiter gegeben.

Callback-Registrierung während der Konstruktion ist solange unproblematisch, wie keine Vererbung im Spiel ist. Dann kann man die Registrierung als letzte Anweisung im Konstruktor-Body machen, also dann, wenn das Objekt bereits fertig initialisiert ist. Sobald Subklassen existieren, kann es unter Umständen nicht mehr gewährleistet werden, daß die Registrierung erst ganz am Ende statt findet.  Dann wird in der Tat ein halbfertiges Objekt registriert.  Solange die this-Referenz nur herumgereicht und irgendwo gespeichert wird, ist das ungefährlich. Man muß aber darauf achten, daß die Methode, die die this-Referenz auf ein noch unfertiges Objekt bekommt, diese Referenz nicht zum Aufruf von Methoden oder zum Zugriff auf die Felder des Objekts verwendet.  Bei einer typischen Callback-Registierung ist das auch nicht der Fall.  Methoden des registrierten Objekts werden typischerweise erst sehr viel später, nach Beendigung der Konstruktion, gerufen.

In unserem Beispiel haben wir genau das mißachtet. Wir haben die this-Referenz auf ein noch unfertiges Objekt an die Registrierungsmethode OrgUnit.addMember() übergeben und die hat sofort eine Methode des halbfertigen Objekts aufgerufen, was zu den erläuterten Problemen geführt hat.
 

Zusammenfassung

Leserzuschrift

Literaturverweise

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Effective Java - Advanced Java Programming Idioms  4 day seminar ( open enrollment and on-site)