6    Eigene Klassen schreiben 

»Das Gesetz ist der abstrakte Ausdruck des allgemeinen an und für sich seienden Willens.«

– Georg Wilhelm Friedrich Hegel (1770–1831)

In den letzten Kapiteln haben wir viel über Objektorientierung erfahren, aber eher von der Benutzerseite her. Wir haben gesehen, wie Objekte aufgebaut werden, und auch einfache Klassen mit statischen Methoden haben wir implementiert. Es wird Zeit, das Wissen um alle objektorientierten Konzepte zu vervollständigen und eigene benutzerdefinierte Datentypen aufzubauen.

 

6.1    Eigene Klassen mit Eigenschaften deklarieren 

Die Deklaration einer Klasse leitet das Schlüsselwort class ein. Im Rumpf der Klasse lassen sich deklarieren:

• Objekt- und Klassenvariablen

• Methoden

• Konstruktoren

• Klassen- sowie Exemplarinitialisierer

• geschachtelte Klassen, Schnittstellen und Aufzählungen

Minimalklasse

Im Mittelpunkt steht eine Süßigkeit, die von der Klasse Candy repräsentiert wird:

Listing 6.1     src/main/java/com/tutego/insel/game/c/v1/Candy.java

package com.tutego.insel.game.c.v1

class Candy { }

Abbildung 6.1     Im UML-Diagramm ist die Klasse »Candy« nur eine umrandete Box.

  Die Klasse hat einen vom Compiler generierten Konstruktor, und new Candy() erzeugt aus diesem Bauplan ein Exemplar. Details zum Konstruktor folgen in Abschnitt 6.5.3, »Der Standard-Konstruktor (default constructor)«. Auf Sichtbarkeitsmodifizierer (wie public) wollen wir erst einmal verzichten, wir setzen uns im späteren Abschnitt 6.2 damit intensiver auseinander.

 

6.1.1    Objektvariablen deklarieren 

Diese Klasse class Candy { } besitzt keine Objektvariablen und kann daher keine Zustände speichern. Geben wir der Süßigkeit drei Objektvariablen: eine für den Namen (Typ String), eine zweite für den Preis (Typ int) und eine dritte für die Anzahl der Süßigkeiten (Typ int).

Listing 6.2     src/main/java/com/tutego/insel/game/c/v2/Candy.java, Ausschnitt

class Candy {

  String name;

  int    price;

  int    quantity;

}

Eine zweite Klasse, Application, erzeugt in der statischen main(…)-Methode zwei Exemplare einer Süßigkeit, beschreibt die Objektvariablen und liest sie aus:

Listing 6.3     src/main/java/com/tutego/insel/game/c/v2/Application.java, Ausschnitt

Candy lollipop = new Candy();

lollipop.name = "Lollipop";

lollipop.price = 12;

lollipop.quantity = 2;

 

Candy licorice = new Candy();

licorice.name = "Licorice";

licorice.price = 22;

 

System.out.printf( "%s, %d × %d = %d%n", // Lollipop, 2 × 12 = 24

                   lollipop.name, lollipop.quantity, lollipop.price,

                   lollipop.quantity * lollipop.price );

System.out.printf( "%s, %d × %d = %d%n", // Licorice, 0 × 22 = 0

                   licorice.name, licorice.quantity, licorice.price,

                   licorice.quantity * licorice.price );

Abbildung 6.2     Das UML-Klassendiagramm zeigt die Abhängigkeiten von »Application« und »Candy«.

Abbildung 6.3     Das UML-Objektdiagramm zeigt die zwei Candy-Instanzen.

  Spätestens, wenn zwei Dateien im Editor offen sind, möchten Tastaturjunkies schnell zwischen den Editoren wechseln. Das geht in IntelliJ mit (Strg)+(_ÿ) und (Strg)+(ª)+(_ÿ).

Initialisierung von Objektvariablen

Anders als lokale Variablen initialisiert die Laufzeitumgebung alle Objektvariablen – das Gleiche gilt für Klassenvariablen, die wir in Abschnitt 6.3 besprechen werden – mit einem Standardwert:

• 0 bei numerischen Werten und char

• false bei boolean

• null bei Referenzvariablen

Gefällt uns das nicht, lassen sich die Variablen mit einem Wert belegen:

class Candy {

  String name;

  int    price;

  int    quantity = 1;

}

Der Ausdruck new Candy().quantity == 1 würde also true ergeben.

Gültigkeitsbereich, Sichtbarkeit und Lebensdauer

Lokale Variablen beginnen ihr Leben in dem Moment, in dem sie deklariert und initialisiert werden. Endet der Block, ist die lokale Variable nicht mehr gültig, und sie kann nicht mehr verwendet werden, da sie aus dem Sichtbarkeitsbereich verschwunden ist. Bei Objektvariablen ist das anders. Eine Objektvariable lebt ab dem Moment, in dem das Objekt mit new aufgebaut wurde, und sie lebt so lange, bis der Garbage-Collector das Objekt wegräumt. Sichtbar und gültig ist die Variable aber immer im gesamten Objekt und in allen Blöcken.[ 144 ](Das gilt nicht für statische Methoden und statische Initialisierungsblöcke, aber diese werden erst später vorgestellt. )

 

6.1.2    Methoden deklarieren 

Zu Objektvariablen gesellen sich Methoden, die üblicherweise auf den Objektvariablen arbeiten. Geben wir der Süßigkeit zwei Methoden:

• totalPrice(): Ermittelt den Gesamtpreis als Produkt aus Anzahl und Preis.

• resetQuantity(): Setzt die Anzahl auf 1 zurück.

Anders als unsere bisherigen statischen Methoden werden diese drei Methoden für Candy Objektmethoden sein, also nicht den Modifizierer static tragen.

Listing 6.4     src/main/java/com/tutego/insel/game/c/v3/Candy.java, Ausschnitt

class Candy {

  String name;

  int    price;

  int    quantity = 1;

 

  int totalPrice() {

    return price * quantity;

  }

 

  void resetQuantity() {

    quantity = 1;

  }

}

Abbildung 6.4     Das UML-Klassendiagramm von »Candy« zeigt drei Objektvariablen und zwei Methoden.

Die Methode totalPrice() bildet das Produkt als Preis und Anzahl und liefert das Ergebnis zurück. resetQuantity() setzt die Produktanzahl auf 1 zurück.

Testen wir die Methoden mit einer Süßigkeit:

Listing 6.5     src/main/java/com/tutego/insel/game/c/v3/Application.java, Ausschnitt

Candy lollipop = new Candy();

lollipop.name = "Lollipop";

lollipop.price = 12;

lollipop.quantity = 2;

System.out.println( lollipop.totalPrice() ); // 24

lollipop.resetQuantity();

System.out.println( lollipop.totalPrice() ); // 12

  Um schnell von einer Methode (oder Variablen) zur anderen zu navigieren, zeigt (Strg)+(O) ein Outline an (dieselbe Ansicht wie in der Ansicht Outline). Im Unterschied zur Ansicht Outline lässt sich in diesem kleinen gelben Fenster mit den Cursor-Tasten navigieren, und ein (¢) befördert uns zur angewählten Methode oder zur angewählten Objektvariablen. Wird in der Ansicht erneut (Strg)+(O) gedrückt, befinden sich dort auch die in den Oberklassen deklarierten Eigenschaften; sie sind grau. Zusätzlich befinden sich hinter den Eigenschaften die Klassennamen.

Methodenaufrufe und Nebeneffekte

Alle Variablen und Methoden einer Klasse sind in der Klasse selbst sichtbar. Das heißt, innerhalb einer Klasse werden die Objektvariablen und Methoden mit ihrem Namen verwendet. Somit greift die Methode totalPrice(…) direkt auf die nötigen Objektvariablen price und quantity zu, um die Programmlogik auszuführen. Dies wird oft für Nebeneffekte (Seiteneffekte) genutzt. Die Methode resetQuantity() ändert ausdrücklich die Objektvariable quantity und verändert so den Zustand des Objekts. totalPrice(…) liest dagegen nur den Zustand, modifiziert ihn aber nicht. Methoden, die Zustände ändern, sollten das in der API-Beschreibung entsprechend dokumentieren. Methoden, die Zustände ändern, heißen auch Mutatoren; Methoden, die lesen, heißen englisch accessor methods.

Objektorientierte und prozedurale Programmierung im Vergleich

Entwickler aus der prozeduralen Welt haben ein anderes Denkmodell verinnerlicht, sodass wir an dieser Stelle die Besonderheit der Objektorientierung noch einmal verdeutlichen wollen. Während in der guten objektorientierten Modellierung die Objekte immer gleichzeitig Zustand und Verhalten besitzen, gibt es in der prozeduralen Welt nur Speicherbereiche, die referenziert werden; Daten und Verhalten liegen hier nicht zusammen. Problematisch wird es, wenn die prozedurale Denkweise in Java-Programmen abgebildet wird. Dazu ein Beispiel: Die Klasse CandyData ist ein reiner Datencontainer für den Zustand, aber Verhalten wird hier nicht deklariert:

Listing 6.6     src/main/java/com/tutego/insel/nonoop/CandyData.java, Ausschnitt

class CandyData {

  String name;

  int    price;

  int    quantity = 1;

}

Anstatt nun die Methoden ordentlich, wie in unserem ersten Beispiel, mit an die Klasse zu hängen, würde in der prozeduralen Welt ein Unterprogramm genau ein Datenobjekt bekommen und von diesem Zustände erfragen oder ändern:

Listing 6.7     src/main/java/com/tutego/insel/nonoop/CandyFunctions.java, Ausschnitt

class CandyFunctions {

  static int totalPrice( CandyData candy ) {

    return candy.price * candy.quantity;

  }

}

Da die Unterprogramme nun nicht mehr an Objekte gebunden sind, können die Methoden statisch sein. Genauso falsch wären aber auch Methoden (egal, ob statisch oder nicht) in der Klasse CandyData, wenn sie ein CandyData-Objekt übergeben bekommen.

Beim Aufruf ist dieser nichtobjektorientierte Ansatz gut zu sehen. Setzen wir in Tabelle 6.1 links den falschen und rechts den korrekt objektorientiert modellierten Weg ein:

CandyData lollipop = new CandyData();

lollipop.price = 12;

int p = CandyFunctions.totalPrice( lollipop );

Candy lollipop = new Candy();

lollipop.price = 12;

int p = lollipop.totalPrice();

Tabelle 6.1     Gegenüberstellung von prozeduraler und objektorientierter Programmierung

Ein Indiz für eine problematische objektorientierte Modellierung ist also, wenn externen Methoden Objekte übergeben werden, anstatt die Methoden selbst an die Objekte zu setzen.

 

6.1.3    Verdeckte (shadowed) Variablen 

Führt eine Methode eine neue Variable ein, so kann der gleiche Variablenname nicht noch einmal in einem inneren Block verwendet werden.

public static void main( String[] args ) {

  int args = 1;    //  Duplicate local variable args

}

Beim Verlassen eines Blocks ist der Variablenname jedoch wieder frei. Folgendes ist daher in Ordnung:

for ( int i = 0; i < 10; i++ )

  System.out.println( i );

for ( int i = 0; i < 10; i++ )

  System.out.println( i );

Grundsätzlich keine Probleme gibt es, wenn eine lokale Variable/Parametervariable genauso heißt wie eine Objektvariable. Wir sprechen in diesem Fall von einer verdeckten Variablen – im Englischen shadowed variable genannt.[ 145 ](https://docs.oracle.com/javase/specs/jls/se14/html/jls-6.html#jls-6.4) Der Compiler wird dann die lokale Variable nutzen und nicht mehr die Objektvariable.

class Candy {

  int price;

  int quantity = 1;



  int totalPrice() {

    int price = quantity;

    price *= price * quantity;

    return price;

  }

}

Verdeckte Variablen sind praktisch, denn ohne so ein Konzept könnte eine neu eingefügte Objektvariable schnell viele Methoden kaputt machen, die zufälligerweise im Rumpf ebenfalls den gleichen Namen nutzen.[ 146 ](Fast alle Programmiersprachen besitzen verdeckte Variablen. Eine Ausnahme ist TypeScript. )

Doch was machen wir, wenn wir eine lokale Variable gleichzeitig mit einer Objektvariablen gleichen Namens nutzen wollen?

 

6.1.4    Die this-Referenz 

In jeder Objektmethode und jedem Konstruktor[ 147 ](Sowie Exemplarinitialisierer, doch der Code landet im Konstruktor. ) steht eine Referenz mit dem Namen this bereit, die auf das eigene Exemplar zeigt. Mit dieser this-Referenz lassen sich elegante Lösungen realisieren, wie die folgenden Beispiele zeigen:

• Die this-Referenz löst das Problem, wenn Parameter oder lokale Variablen Objektvariablen verdecken.

• Liefert eine Methode als Rückgabe die this-Referenz auf das aktuelle Objekt, lassen sich Methoden der Klasse einfach hintereinandersetzen.

• Mit der this-Referenz lässt sich einer anderen Methode eine Referenz auf uns selbst geben.

Überdeckte Objektvariablen nutzen

Trägt eine lokale Variable den gleichen Namen wie eine Objektvariable, so verdeckt sie diese; das haben wir eben im vorherigen Abschnitt gesehen. Das ist so weit nicht tragisch und wird nur dann zum Problem, wenn später Zugriff auf die Objektvariable nötig ist.

Das heißt aber nicht, dass auf die Objektvariable nicht mehr zugegriffen werden kann. Die this-Referenz zeigt auf das aktuelle Objekt, und damit ist auch ein Zugriff auf Objekteigenschaften jederzeit möglich. Im folgenden Beispiel wird ebenfalls eine lokale Variable price eingeführt, doch Zugriff auf die Objektvariable gelingt über this.price:

Listing 6.8     src/main/java/com/tutego/insel/game/c/v4/Candy.java, Ausschnitt

class Candy {

  int price;

  int quantity = 1;

 

  int totalPrice() {

    int price = quantity * this.price;

    return price;

  }

}

this für Setter nutzen

Häufiger Einsatzort für das this sind Methoden oder Konstruktoren, die Zustände initialisieren. Gerne nennen Entwickler die Parametervariablen so wie die Exemplarvariablen, um damit eine starke Zugehörigkeit auszudrücken. Schreiben wir also eine Methode setName(String):

class Candy {

  String name;

 

  public void setName( String name ) {

    this.name = name;

  }

} 

Das an setName(String) übergebene Objekt soll die Objektvariable name initialisieren. So greift this.name auf die Objektvariable direkt zu, sodass die Zuweisung this.name = name die Objektvariable mit dem Argument initialisiert.

this für kaskadierte Methoden *

Die append(…)-Methoden bei StringBuilder liefern die this-Referenz, sodass sich Folgendes schreiben lässt:

StringBuilder sb = new StringBuilder();

sb.append( "Android oder iPhone" ).append( '?' );

Jedes append(…) liefert das StringBuilder-Objekt, auf dem es aufgerufen wird – wir können also Methoden kaskadiert anhängen oder es bleiben lassen.

Wir wollen diese Möglichkeit nutzen und eine andere Implementierung der Candy-Klasse programmieren, sodass die Methoden name(String) und price(int) Name und Preis zuweisen. Beide Methoden liefern ihr eigenes Candy-Objekt über die this-Referenz zurück:

Listing 6.9     src/main/java/com/tutego/insel/game/c/v5/Candy.java, Ausschnitt

class Candy {

  String name;

  int    price;

 

  Candy name( String name ) {

    this.name = name;

    return this;

  }

 

  String name() {

    return name;

  }

 

  Candy price( int price ) {

    this.price = price;

    return this;

  }

 

  int price() {

    return price;

  }

}

Erzeugen wir ein Candy, und kaskadieren wir die Methoden:

Listing 6.10     src/main/java/com/tutego/insel/game/c/v5/Application.java, Ausschnitt

Candy candy = new Candy().name( "Nerds Candy" ).price( 80 );

System.out.printf( "%s %d%n", candy.name(), candy.price() ); // Nerds Candy 80

Abbildung 6.5     UML-Klassendiagramm für »Candy« mit Fluent-API

Der Ausdruck new Candy() liefert eine Referenz, die wir sofort für den Methodenaufruf nutzen. Da name(…) wiederum eine Objektreferenz vom Typ Candy liefert, ist dahinter direkt .price(…) möglich. Die Verschachtelung von name("Nerds Candy").price(80) bewirkt also, dass Name und Preis gesetzt werden und der jeweils nächste Methodenaufruf in der Kette über this eine Referenz auf dasselbe Objekt, aber mit verändertem internem Zustand bekommt.

Beispiele dieser Bauart sind in der Java-Bibliothek an einigen Stellen zu finden. Sie werden auch Builder genannt. Sie bestehen in der Regel nur aus den schreibenden Methoden.

Sich selbst mit this übergeben

Möchte sich ein Objekt A einem anderen Objekt B mitteilen, damit B das andere Objekt A »kennt«, so funktioniert das gut mit der this-Referenz. Demonstrieren wir das an einem »Ich bin dein Vater«-Beispiel: Die zwei Klassen Luke und Darth repräsentieren zwei Personen, wobei Luke eine Objektvariable dad für seinen Vater hat:

Listing 6.11     src/main/java/com/tutego/insel/oop/LukeAndVader.java, Teil 1

class Luke {

  Darth dad;

}



class Darth {

  void revealTruthTo( Luke son ) {

    son.dad = this;

  }

}

Spannend ist die Methode revealTruthTo(Luke), denn sie setzt beim übergebenen Luke-Objekt die Objektvariable dad mit der this-Referenz. Damit kennt Luke seinen Vater, was in folgender Klasse getestet wird:

Listing 6.12     src/main/java/com/tutego/insel/oop/LukeAndVader.java, Teil 2

Luke luke = new Luke();

Darth vader = new Darth();

System.out.println( luke.dad ); // null

vader.revealTruthTo( luke );

System.out.println( luke.dad ); // com.tutego.insel.oop.Darth@01234567