2.7    Methoden einer Klasse 

In objektorientierten Programmen interagieren zur Laufzeit Objekte miteinander und senden sich gegenseitig Nachrichten als Aufforderung, etwas zu machen. Diese Aufforderungen resultieren in einem Methodenaufruf, in dem Anweisungen stehen, die dann ausgeführt werden. Das Angebot eines Objekts, also das, was es »kann«, wird in Java durch Methoden ausgedrückt.

Wir haben schon mehrere Methoden kennengelernt und am häufigsten println(…) in unseren Beispielen eingesetzt. Sie ist eine Methode vom out-Objekt. Ein anderes Programmstück schickt nun eine Nachricht an das out-Objekt, die println(…)-Methode auszuführen. Im Folgenden werden wir den aktiven Teil des Nachrichtenversendens nicht mehr so genau betrachten, sondern wir sagen nur noch, dass eine Methode aufgerufen wird.

Für die Deklaration von Methoden gibt es drei Gründe:

• Wiederkehrende Programmteile sollen nicht immer wieder programmiert, sondern an einer Stelle angeboten werden. Änderungen an der Funktionalität lassen sich dann leichter durchführen, wenn der Code lokal zusammengefasst ist.

• Komplexe Programme werden in kleine Teilprogramme zerlegt, damit die Komplexität des Programms heruntergebrochen wird. Damit ist der Kontrollfluss leichter zu erkennen.

• Die Operationen einer Klasse, also das Angebot eines Objekts, sind ein Grund für Methodendeklarationen in einer objektorientierten Programmiersprache. Daneben gibt es aber noch weitere Gründe, die für Methoden sprechen. Sie werden im Folgenden erläutert.

 

2.7.1    Bestandteile einer Methode 

Eine Methode setzt sich aus mehreren Bestandteilen zusammen. Dazu gehören der Methodenkopf (kurz Kopf) und der Methodenrumpf (kurz Rumpf). Der Kopf besteht aus einem Rückgabetyp (auch Ergebnistyp genannt), dem Methodennamen und einer optionalen Parameterliste.

Nehmen wir die bekannte statische main(String[])-Methode:

public static void main( String[] args ) {

  System.out.println( "Wie siehst du denn aus? Biste gerannt?" );

}

Sie hat folgende Bestandteile:

• Die statische Methode liefert keine Rückgabe, daher ist der »Rückgabetyp« void. (An dieser Stelle sollte bemerkt werden, dass void in Java kein Typ ist.) void heißt auf Deutsch übersetzt »frei«, »die Leere« oder »Hohlraum«.

• Der Methodenname ist main.

• Die Parameterliste ist String[] args.

• Der Rumpf besteht nur aus der Bildschirmausgabe.

Die Signatur einer Methode

Der Methodenname und die Parameterliste bestimmen die Signatur einer Methode; der Rückgabetyp und Ausnahmen gehören nicht dazu.[ 97 ](Um es ganz präzise zu machen: Typparameter gehören auch zur Signatur – sie sind Bestandteil von Kapitel 10, »Besondere Typen der Java SE«. ) Die Parameterliste ist durch die Anzahl, die Reihenfolge und die Typen der Parameter beschrieben. Pro Klasse darf es nur eine Methode mit derselben Signatur geben, sonst meldet der Compiler einen Fehler. Da die Methoden void main(String[] args) und String main(String[] arguments) die gleiche Signatur (main, String[]) besitzen – die Namen der Parameter spielen keine Rolle –, können sie nicht zusammen in einer Klasse deklariert werden (später werden wir sehen, dass Unterklassen durchaus gewisse Sonderfälle zulassen).

printSum( a, b ) print a + b

 

2.7.2    Signatur-Beschreibung in der Java-API 

In der Java-Dokumentation sind alle Methoden mit ihren Rückgaben und Parametern inklusive möglicher Ausnahmen genau definiert. Betrachten wir die Dokumentation der statischen Methode max(int, int) der Klasse Math:

Abbildung 2.9    Die Online-API-Dokumentation für »Math.max()«

Die Hilfe (siehe Abbildung 2.9) gibt Informationen über die komplette Signatur der Methode. Der Rückgabetyp ist ein int, die statische Methode heißt max, und sie erwartet genau zwei int-Zahlen. Verschwiegen haben wir die Schlüsselwörter public und static, die sogenannten Modifizierer. public gibt die Sichtbarkeit an und sagt, wer diese Methode nutzen kann.

• Im Fall von public bedeutet es, dass jeder diese Methode verwenden kann. Das Gegenteil ist private: In dem Fall kann nur das Objekt selbst diese Methode nutzen. Das ist sinnvoll, wenn Methoden benutzt werden, um die Komplexität zu verkleinern und Teilprobleme zu lösen. Private Methoden werden in der Regel nicht in der Hilfe angezeigt, da sie ein Implementierungsdetail sind.

• Das Schlüsselwort static zeigt an, dass sich die Methode mit dem Klassennamen nutzen lässt, also kein Exemplar eines Objekts nötig ist.

Weitere Modifizierer und Ausnahmen *

Es gibt Methoden, die noch andere Modifizierer und eine erweiterte Signatur besitzen. Ein weiteres Beispiel aus der API zeigt Abbildung 2.10. Die Sichtbarkeit dieser Methode ist protected. Das bedeutet: Nur abgeleitete Klassen und Klassen im gleichen Verzeichnis (Paket) können diese Methode nutzen. Ein zusätzlicher Modifizierer ist final, der in einer Vererbung der Unterklasse nicht erlaubt, die Methode zu überschreiben und ihr neuen Programmcode zu geben. Zum Schluss folgt hinter dem Schlüsselwort throws eine Ausnahme. Diese sagt etwas darüber aus, welche Fehler die Methode verursachen kann und worum sich der Programmierer kümmern muss. Im Zusammenhang mit der Vererbung werden wir noch über protected und final sprechen. Dem Ausnahmezustand widmen wir Kapitel 8, »Ausnahmen müssen sein«. Die Dokumentation zeigt mit »Since: 1.1« an, dass es die Methode seit Java 1.1 gibt. Die Information kann auch an der Klasse festgemacht sein.

Abbildung 2.10    Ausschnitt aus der API-Dokumentation für die Klasse java.net.ServerSocket

 

2.7.3    Aufruf einer Methode 

Da eine Methode immer einer Klasse oder einem Objekt zugeordnet ist, muss der Eigentümer beim Aufruf angegeben werden. Im Fall von System.out.println() ist println() eine Methode vom out-Objekt. Wenn wir das Maximum zweier Fließkommazahlen mit dem Aufruf Math.max(a, b) bilden, dann ist max(…) eine (statische) Methode der Klasse Math. Für den Aufrufer ist damit immer ersichtlich, wer diese Methode anbietet, also auch, wer diese Nachricht entgegennimmt. Was der Aufrufer nicht sieht, ist die Arbeitsweise der Methode. Der Methodenaufruf verzweigt in den Programmcode, aber der Aufrufer weiß nicht, was dort geschieht. Er betrachtet nur das Ergebnis.

Die aufgerufene Methode wird mit ihrem Namen genannt. Die Parameterliste wird durch ein Klammerpaar umschlossen. Diese Klammern müssen auch dann gesetzt werden, wenn die Methode keine Parameter enthält. Die Anzahl und Typen der übergebenen Werte müssen zur Deklaration der Methode passen – bei Math.max(…) sind exakt zwei Übergaben nötig, und stimmt die Anzahl oder stimmen die Typen nicht, gibt es einen Compilerfehler.[ 98 ](Bei JavaScript ist das anders. Dort lassen sich mehr Argumente übergeben und es gibt keinen Fehler. )

Will was, will nix, gibt nix, gibt was

Eine Methode wie System.out.println() gibt nichts als Ergebnis einer »Berechnung« zurück. Anders die statischen Methoden Math.max(…) und Math.random(), sie liefern ein Ergebnis. Damit ergeben sich vier unterschiedliche Typen von Methoden:

Tabelle 2.15    Methoden mit Rückgabewerten

Die folgenden Abschnitte gehen diese vier Fälle der Reihe nach durch:

• Methode ohne Parameter und ohne Rückgabe

• Methode mit Parameter und ohne Rückgabe

• Methode ohne Parameter und mit Rückgabe

• Methode mit Parameter und mit Rückgabe

 

2.7.4    Methoden ohne Parameter deklarieren 

Die einfachste Methode besitzt keinen Rückgabewert und keine Parameter. Der Programmcode steht in geschweiften Klammern hinter dem Kopf und bildet damit den Körper der Methode. Gibt die Methode nichts zurück, dann wird void vor den Methodennamen geschrieben. Falls die Methode etwas zurückgibt, wird der Typ der Rückgabe anstelle von void geschrieben.

Schreiben wir eine statische Methode ohne Rückgabe und Parameter, die etwas auf dem Bildschirm ausgibt:

Listing 2.35    src/main/java/FriendlyGreeter.java

class FriendlyGreeter {



  static void greet() {

    System.out.println( "Guten Morgen. Oh, und falls wir uns nicht mehr" +

                        " sehen, guten Tag, guten Abend und gute Nacht!" );

  }



  public static void main( String[] args ) {

    greet();

  }

}

Eigene Methoden können natürlich wie Bibliotheksmethoden heißen, da sie zu unterschiedlichen Klassen gehören. Statt greet() hätten wir also auch den Namen println() vergeben dürfen.

  Eine gedrückte (Strg)-Taste und ein Mausklick auf einen Bezeichner lässt Eclipse zur Deklaration springen. Ein Druck auf (F3) hat den gleichen Effekt. Steht der Cursor in unserem Beispiel auf dem Methodenaufruf greet() und wird (F3) gedrückt, dann springt Eclipse zur Definition in Zeile 3 und hebt den Methodennamen hervor.

 

2.7.5    Statische Methoden (Klassenmethoden) 

Bisher haben wir nur mit statischen Methoden (auch Klassenmethoden genannt) gearbeitet. Das Besondere daran ist, dass die statischen Methoden nicht an einem Objekt hängen und daher immer ohne explizit erzeugtes Objekt aufgerufen werden können. Das heißt, statische Methoden gehören zu Klassen an sich und sind nicht mit speziellen Objekten verbunden. Am Aufruf unserer statischen Methode greet() lässt sich ablesen, dass hier kein Objekt gefordert ist, mit dem die Methode verbunden ist. Das ist möglich, denn die Methode ist als static deklariert und innerhalb der Klasse lassen sich alle Methoden einfach mit ihrem Namen nutzen.

Statische Methoden müssen explizit mit dem Schlüsselwort static kenntlich gemacht werden. Fehlt der Modifizierer static, so deklarieren wir damit eine Objektmethode, die wir nur aufrufen können, wenn wir vorher ein Objekt angelegt haben. Das heben wir uns aber bis Kapitel 3, »Klassen und Objekte«, auf. Die Fehlermeldung sollte uns aber keine Angst machen. Lassen wir von der greet()-Deklaration das static weg und ruft die statische main(…)-Methode wie jetzt ohne Aufbau eines Objekts die dann nicht mehr statische Methode greet() auf, so gibt es den Compilerfehler »Cannot make a static reference to the non-static method greet() from the type FriendlyGreeter«.

Ist die statische Methode in der gleichen Klasse wie der Aufrufer deklariert – in unserem Fall main(…) und greet() in FriendlyGreeter –, so ist der Aufruf allein mit dem Namen der Methode eindeutig. Befinden sich jedoch Methodendeklaration und Methodenaufruf in unterschiedlichen Klassen, so muss der Aufrufer den Namen der Klasse nennen; wir haben so etwas schon einmal bei Aufrufen wie Math.random(…) gesehen.

class FriendlyGreeter {

 static void greet() {

  System.out.println( "Moin!" );

 }

}

class FriendlyGreeterCaller {

 public static void main( String[] args ) {

  FriendlyGreeter.greet();

 }

}

 

2.7.6    Parameter, Argument und Wertübergabe 

Einer Methode können Werte übergeben werden, die sie dann in ihre Arbeitsweise einbeziehen kann. Der Methode println(2001) ist zum Beispiel ein Wert übergeben worden. Sie wird damit zur parametrisierten Methode.

static void printMax( double a, double b ) {

  if ( a > b )

    System.out.println( a );

  else

    System.out.println( b );

}

Um die an Methoden übergebenen Werte anzusprechen, gibt es formale Parameter. Von unserer statischen Methode printMax(double a, double b) sind a und b die formalen Parameter der Parameterliste. Jeder Parameter wird durch ein Komma getrennt aufgelistet, wobei für jeden Parameter der Typ angegeben sein muss; eine Kurzform wie bei der sonst üblichen Variablendeklaration wie double a, b ist nicht möglich. Jede Parametervariable einer Methodendeklaration muss natürlich einen anderen Namen tragen, sonst gibt es keine Einschränkungen.

Argumente (aktuelle Parameter)

Der Aufrufer der Methode muss für jeden Parameter ein Argument angeben. Die im Methodenkopf deklarierten Parameter sind letztendlich lokale Variablen im Rumpf der Methode. Beim Aufruf initialisiert die Laufzeitumgebung die lokalen Variablen mit den an die Methode übergebenen Argumenten. Rufen wir unsere parametrisierte Methode etwa mit printMax(10, 20) auf, so sind die Literale 10 und 20 Argumente (aktuelle Parameter der Methode). Beim Aufruf der Methode setzt die Laufzeitumgebung die Argumente in die lokalen Variablen, kopiert also den Wert 10 in die Parametervariable a und 20 in die Parametervariable b. Innerhalb des Methodenkörpers gibt es so Zugriff auf die von außen übergebenen Werte.

Das Ende des Methodenblocks bedeutet automatisch das Ende für die Parametervariablen. Der Aufrufer weiß auch nicht, wie die internen Parametervariablen heißen. Eine Typumwandlung von int in double nimmt der Compiler in unserem Fall automatisch vor. Die Argumente müssen vom Typ her natürlich passen, und es gelten die für die Typumwandlung bekannten Regeln.

Abbildung 2.11    Die Begriffe »Parameter« und »Argument«

Wertübergabe per Call by Value

Wenn eine Methode aufgerufen wird, dann gibt es in Java ein bestimmtes Verfahren, in dem jedes Argument einer Parametervariablen übergeben wird. Diese Technik heißt Parameterübergabe-Mechanismus. Viele Programmiersprachen verfügen über eine ganze Reihe von verwirrenden Möglichkeiten. Java kennt nur einen einfachen Mechanismus der Wertübergabe (engl. call by value, selten auch copy by value genannt). Ein Beispiel zum Methodenaufruf macht das deutlich:

int i = 2;

printMax( 10, i );         // 10 geht in a und 2 geht in b

Unsere aufgerufene Methode printMax(double a, double b) bekommt zunächst 10 in die Variable a kopiert und dann den Inhalt der Variablen i (in unserem Beispiel 2) in b. Auf keinen Fall gibt der Aufrufer Informationen über den Speicherbereich von i an die Methode mit. In dem Moment, in dem die Methode aufgerufen wird, erfragt die Laufzeitumgebung die Belegung von i und initialisiert damit die Parametervariable b. Ändert printMax(…) intern seine Variable b, so ändert dies nur die lokale Variable b (überschreibt also 2), aber die Änderung in der Methode ist für das außenstehende i ohne Konsequenz; i bleibt weiterhin bei 2. Durch diese Aufrufart kommt auch die Bezeichnung Copy by Value zustande. Lediglich der Wert wird übergeben (kopiert) und kein Verweis auf die Variable.[ 99 ](… wie dies Referenzen in C++ tun. )

Auswertung der Argumentliste von links nach rechts *

Bei einem Methodenaufruf werden erst alle Argumente ausgewertet und anschließend der Methode übergeben. Dies bedeutet im Besonderen, dass Untermethoden ausgewertet und Zuweisungen gemacht werden können. Fehler führen dann zu einem Abbruch des Methodenaufrufs. Bis zum Fehler werden alle Ausdrücke ausgewertet.

int i = 1;

System.out.println( Math.max( i++, --i ) );

 

2.7.7    Methoden vorzeitig mit return beenden 

Läuft eine Methode bis zum Ende durch, dann ist die Methode damit beendet, und es geht zurück zum Aufrufer. In Abhängigkeit von einer Bedingung kann eine Methode jedoch vor dem Ende des Ablaufs mit einer return-Anweisung beendet werden. Das ist nützlich bei Methoden, die abhängig von Parametern vorzeitig aussteigen wollen. Wir können uns vorstellen, dass vor dem Ende der Methode automatisch ein verstecktes return steht. Ein unnötiges return am Ende des Methodenrumpfs sollte nicht geschrieben werden.

static void printSqrt( double d ) {

  if ( d < 0 ) {

    System.out.println( "Keine Wurzel aus negativen Zahlen!" );

    return;

  }

  System.out.println( Math.sqrt( d ) );

}

 

2.7.8    Nicht erreichbarer Quellcode bei Methoden * 

Folgt direkt hinter einer return-Anweisung Quellcode, so ist dieser nicht erreichbar – im Sinne von nicht ausführbar. return beendet immer die Methode und kehrt zum Aufrufer zurück. Folgt nach dem return noch Quelltext, meldet der Compiler einen Fehler:

public static void main( String[] args ) {

  int i = 1;

  return;

  i = 2;              //  Unreachable code!

}

Reduzieren wir eine Anweisung bis auf das Nötigste, das Semikolon, so führt dies bisweilen zu amüsanten Ergebnissen:

public static void main( String[] args ) {

  ;return;;           // 

}

Das Beispiel enthält zwei Null-Anweisungen: eine vor dem return und eine dahinter. Doch das zweite Semikolon hinter dem return ist unzulässig, da es eine nicht erreichbare Anweisung darstellt.

 

2.7.9    Methoden mit Rückgaben 

Damit Methoden Rückgabewerte an den Aufrufer liefern können, müssen zwei Dinge gelten:

• Eine Methodendeklaration bekommt einen Rückgabetyp ungleich void.

• Eine return-Anweisung gibt einen Wert zurück.

static double largerRandom() {

  return Math.random() * 100;

}

Fehlt der Ausdruck und ist nur ein einfaches return vorhanden, meldet der Compiler einen Programmfehler, dass ein Ausdruck nötig ist oder die Methode nichts zurückgeben darf.

  Eclipse erkennt, ob ein Rückgabetyp fehlt, und schlägt einen passenden Typ vor, wenn man (Strg)+(1) drückt.

Rückgaben abhängig von Eingaben

Statische Methoden wie Math.max(…) liefern in Abhängigkeit von den Argumenten ein Ergebnis zurück. Für den Aufrufer ist die Implementierung egal; er abstrahiert und nutzt lediglich die Methode statt eines Ausdrucks.

static double avg( double x, double y ) {

  return (x + y) / 2;

}

Rückgaben nutzen *

Der Rückgabewert muss an der Aufrufstelle nicht zwingend benutzt werden. Berechnet unsere Methode den Durchschnitt zweier Zahlen, ist es wohl eher ein Programmierfehler, den Rückgabewert nicht zu verwenden. Häufig passiert das bei den String-Methoden, die String-Objekte nicht modifizieren, sondern neue String-Objekte zurückgeben.

String s = "Ja";

System.out.println( s.concat( "va" ) ); // Java

s.concat( "va" );                       // Rückgabe ignoriert, Fehler!

System.out.println( s );                // Ja

Mehrere Ausstiegspunkte mit return

Für Methoden mit Rückgabewert gilt ebenso wie für void-Methoden, dass es mehr als ein return geben kann. Aber wird irgendein return »getroffen«, ist Schluss mit der Methode, und es geht zurück zum Aufrufer.

Schauen wir uns dazu eine Methode an, die das Vorzeichen einer Zahl ermittelt und +1, 0 oder –1 zurückgibt, wenn die Zahl entweder positiv, null oder negativ ist:

static int sign( int value ) {

  if ( value < 0 )

    return -1;

  else if ( value > 0 )

    return +1;

  else

    return 0;

}

Bei genauer Betrachtung fällt auf, dass auf keinen Fall ein anderer Test durchgeführt werden kann, wenn ein return die Methode beendet. Der Programmcode lässt sich umschreiben, denn in if-Anweisungen mit weiteren else-if-Alternativen und Rücksprung ist die Semantik die gleiche, wenn das else-if durch ein einfaches if ersetzt wird. Eine äquivalente sign(int)-Methode wäre:

static int sign( int value ) {

  if ( value < 0 )

    return -1;

  if ( value > 0 )

    return +1;

  return 0;

}

Kompakte Rümpfe bei boolean-Rückgaben

Ist die Rückgabe ein Wahrheitswert, so kann oftmals die Implementierung gekürzt werden, wenn ein Ausdruck vorher ausgewertet wird, der den Rückgabewert direkt bestimmt. Gewisse Konstruktionen lassen sich kompakter schreiben:

if ( Bedingung )

 return true;

else

 return false;

return Bedingung;

if ( Bedingung )

 return false;

else

 return true;

return ! Bedingung;

return Bedingung ? true : false;

return Bedingung;

return Bedingung ? false : true;

return ! Bedingung;

Tabelle 2.16    Codeoptimierungen

Schummeln ohne return geht nicht

Jeder denkbare Programmfluss einer Methode mit Rückgabe muss mit einem return value; beendet werden. Der Compiler verfügt über ein scharfes Auge und merkt, wenn es einen Programmpfad gibt, der nicht zu einem return-Abschluss führt.

static int isLastBitSet( int i ) {      //  Compilerfehler

  switch ( i & 1 ) {

    case 0: return 0;

    case 1: return 1;

  }

}

Bei den Dingen, die für den Benutzer meistens offensichtlich sind, muss der Compiler passen, da er die Bedeutung nicht durchschaut. Ähnliches würde für eine Wochenmethode gelten, die mit einem Ganzzahl-Argument (0 bis 6) einen Wochentag als String zurückgibt. Wenn wir die Fälle 0 = Montag bis 6 = Sonntag beachten, dann kann in unseren Augen ein Wochentag nicht 99 sein. Der Compiler kennt aber die Methode nicht und weiß nicht, dass der Wertebereich beschränkt ist. Das Problem ließe sich mit einem default leicht beheben.

static String posOrNeg( double d ) {   //  Compilerfehler

  if ( d >= 0 )

    return "pos";



  if ( d < 0 )

    return "neg";

}

Überraschenderweise ist dieser Programmcode ebenfalls fehlerhaft. Denn obwohl er offensichtlich für positive oder negative Zahlen den passenden String zurückgibt, gibt es einen Fall, den diese Methode nicht abdeckt. Wieder gilt, dass der Compiler nicht erkennen kann, dass der zweite Ausdruck eine Negation des ersten sein soll. Es gibt aber noch einen zweiten Grund, der damit zu tun hat, dass es in Java spezielle Werte gibt, die keine Zahlen sind, denn die Zahl d kann auch ein NaN (Not a Number) als Quadratwurzel aus einer negativen Zahl sein. Diesen speziellen Wert überprüft posOrNeg(double) nicht. Als Lösung für den einfachen Fall ohne NaN reicht es, aus dem zweiten if und der Abfrage einfach ein else zu machen oder die Anweisung auch gleich wegzulassen bzw. mit dem Bedingungsoperator im Methodenrumpf kompakt zu schreiben: return d >= 0 ? "pos" : "neg";.

Methoden, die einen Fehlerwert wie 1 zurückliefern, sind häufig so implementiert, dass am Ende immer automatisch der Fehlerwert zurückgeliefert und dann in der Mitte die Methode bei passendem Ende verlassen wird.

Fallunterscheidungen mit Ausschlussprinzip *

Eine Methode between(a, x, b) soll testen, ob ein Wert x zwischen a (untere Schranke) und b (obere Schranke) liegt. Bei Methoden dieser Art ist es immer sehr wichtig, darauf zu achten und es zu dokumentieren, ob der Test auf echt kleiner (<) oder kleiner gleich (<=) durchgeführt werden soll. Wir wollen hier auch die Gleichheit betrachten.

Für die Implementierung gibt es zwei Lösungen, wobei die meisten Programmierer zur ersten Lösung neigen. Die erste Lösungsidee zeigt sich in einer mathematischen Gleichung. Wir möchten gerne a <= x <= b schreiben, doch ist dies in Java nicht erlaubt.[ 100 ](… im Gegensatz zur Programmiersprache Python. ) So müssen wir einen Und-Vergleich anstellen, der etwa so lautet: Ist a <= x && x <= b, dann liefere true zurück. In Form einer kompletten Methode sieht das so aus:

static boolean between( int a, int x, int b ) {

  return a <= x && x <= b;

}

Die zweite Implementierung zeigt, dass sich das Problem auch ohne Und-Vergleich durch das Ausschlussprinzip lösen lässt:

static boolean between( int a, int x, int b ) {

  if ( x < a )

    return false;



  if ( x <= b )

    return true;



  return false;

}

Mit verschachtelten Anfragen sieht das dann so aus:

static boolean between( int a, int x, int b ) {

  if ( a <= x )

    if ( x <= b )

      return true;



  return false;

}

Ob Programmierer die Variante mit dem Und-Operator oder dem verschachtelten if nutzen, ist oft Geschmacksache, aber die am besten lesbare Lösung sollte gewinnen, und das dürfte in dem Fall die mit dem Und sein.

 

2.7.10    Methoden überladen 

Eine Methode ist gekennzeichnet durch Rückgabewert, Name, Parameter und unter Umständen durch Ausnahmefehler, die sie auslösen kann. Java erlaubt es, den Namen der Methode beizubehalten, aber andere Parameter einzusetzen. Eine Methode nennt man überladen, wenn sie unter dem gleichen Namen mehrfach auftaucht und unterschiedliche Parameterlisten hat. Das ist auf zwei Arten möglich:

• Eine Methode heißt gleich, unterscheidet sich aber in der Anzahl der Parameter.

• Eine Methode heißt gleich, hat aber für den Compiler unterscheidbare Parametertypen.

Anwendungen für den ersten Fall gibt es viele. Der Name einer Methode soll ihre Aufgabe beschreiben, aber nicht die Typen der Parameter, mit denen sie arbeitet, extra erwähnen. Das ist bei anderen Sprachen üblich, doch nicht in Java. Sehen wir uns als Beispiel die in der Mathe-Klasse Math angebotene statische Methode max(…) an. Sie ist mit den Parametertypen int, long, float und double deklariert – das ist viel schöner als etwa separate Methoden maxInt(…) und maxDouble(…).

static double avg( int x, int y ) {

  return (x + y) / 2.;

}

static double avg( double x, double y ) {

  return (x + y) / 2;

}

static double avg( double x, double y, double z ) {

  return (x + y + z) / 3;

}

static double avg( int x, int y, int z ) {

  return (x + y + z) / 3.;

}

static double largerRandom() { return Math.random() * 100; }

static int largerRandom() { return (int)(Math.random() * 100); } 

print(…) und println(…) sind überladen *

Die bekannten print(…) und println(…) sind überladene Methoden, die etwa wie folgt deklariert sind:

class PrintStream {

  …

  void print( int    arg ) { … }

  void print( String arg ) { … }

  void print( double arg ) { … }

  …

}

Wird nun die Methode print(…) mit irgendeinem Objekttyp aufgerufen, dann wird die am besten passende Methode herausgesucht. Das funktioniert selbst bei beliebigen Objekten, wie Abschnitt 7.5.2, »Implementierung von System.out.println(Object)«, zeigt.

Negative Beispiele und schlaue Leute *

Oft verfolgt auch die Java-Bibliothek die Strategie mit gleichen Namen und unterschiedlichen Typen. Es gibt allerdings einige Ausnahmen. In der Grafikbibliothek finden sich die folgenden drei Methoden:

• drawString( String str, int x, int y )

• drawChars( char[] data, int offset, int length, int x, int y )

• drawBytes( byte[] data, int offset, int length, int x, int y )

Das ist äußerst hässlich und schlechter Stil.

Ein anderes Beispiel findet sich in der Klasse DataOutputStream. Hier heißen die Methoden etwa writeInt(…), writeChar(…) usw. Obwohl wir dies auf den ersten Blick verteufeln würden, ist diese Namensgebung sinnvoll. Ein Objekt vom Typ DataOutputStream dient zum Schreiben von primitiven Werten in einen Datenstrom. Gäbe es in DataOutputStream die überladenen Methoden write(byte), write(short), write(int), write(long) und write(char) und würden wir sie mit write(21) füttern, dann hätten wir das Problem, dass die Typumwandlung von Java die Daten automatisch anpasst und der Datenstrom mehr Daten beinhalten würde, als wir wünschen. Denn write(21) ruft nicht etwa write(short) auf und schreibt zwei Bytes, sondern write(int) und schreibt somit vier Bytes. Um also die Übersicht über die geschriebenen Bytes zu behalten, ist eine ausdrückliche Kennzeichnung der Datentypen in manchen Fällen gar nicht so dumm.

 

2.7.11    Gültigkeitsbereich 

Variablen können in jedem Block und in jeder Klasse[ 101 ](Das sind die sogenannten Objektvariablen oder Klassenvariablen, doch dazu später mehr in Kapitel 6, »Eigene Klassen schreiben«. ) deklariert werden. Jede Variable hat einen Gültigkeitsbereich (engl. scope), auch Geltungsbereich genannt. Nur in ihrem Gültigkeitsbereich kann das Java-Programm auf die Variable zugreifen, außerhalb des Gültigkeitsbereichs nicht. Genauer gesagt: Im Block und in den tiefer geschachtelten Blöcken ist die Variable gültig. Der lesende Zugriff ist nur dann erlaubt, wenn die Variable auch initialisiert wurde.

Der Gültigkeitsbereich bestimmt direkt die Lebensdauer der Variablen. Eine Variable ist nur in dem Block »lebendig«, in dem sie deklariert wurde. In diesem Block ist die Variable lokal.

Dazu ein Beispiel mit zwei statischen Methoden:

Listing 2.37    src/main/java/Scope.java

public class Scope {



  public static void main( String[] args ) {

    int foo = 0;



    {

      int bar = 0;                // bar gilt nur in diesem Block

      System.out.println( bar );

      System.out.println( foo );

    }





    System.out.println( foo );

    System.out.println( bar ); //  Fehler: bar cannot be resolved

  }



  static void qux() {

    int foo, baz;              // foo hat nichts mit foo aus main() zu tun



    {

      int baz;                 //  Fehler: Duplicate local variable baz

    }

  }

}

Zu jeder Zeit können Blöcke aufgebaut werden. Außerhalb des Blocks sind deklarierte Variablen nicht gültig. Nach Abschluss des inneren Blocks, der bar deklariert, ist ein Zugriff auf bar nicht mehr möglich; auf foo ist der Zugriff innerhalb der statischen Methode main(…) weiterhin erlaubt. Dieses foo ist aber ein anderes foo als in der statischen Methode qux(). Eine Variable im Block ist so lange gültig, bis der Block durch eine schließende geschweifte Klammer beendet ist.

Innerhalb eines Blocks können Variablennamen nicht genauso gewählt werden wie Namen lokaler Variablen eines äußeren Blocks oder wie die Namen für die Parameter einer Methode. Das zeigt die zweite statische Methode am Beispiel der Deklaration baz. Obwohl andere Programmiersprachen (C++ sei genannt) diese Möglichkeit erlauben – und auch eine Syntax anbieten, um auf eine überschriebene lokale Variable eines höheren Blocks zuzugreifen –, haben sich die Java-Sprachentwickler dagegen entschieden. Gleiche Namen in den inneren und äußeren Blöcken sind nicht erlaubt. Das ist auch gut so, denn es minimiert Fehlerquellen. Die in Methoden deklarierten Parameter sind ebenfalls lokale Variablen und gehören zum Methodenblock.

 

2.7.12    Vorgegebener Wert für nicht aufgeführte Argumente * 

Überladene Methoden lassen sich gut verwenden, wenn vorinitialisierte Werte bei nicht vorhandenen Argumenten genutzt werden sollen. Ist also ein Parameter nicht belegt, soll ein Standardwert eingesetzt werden. Um das zu erreichen, überladen wir einfach die Methode und rufen die andere Methode mit dem Standardwert passend auf (die Sprachen C# und C++ definieren in der Sprachgrammatik eine Möglichkeit für optionale Argumente, die wir in Java nicht haben).

static double tax( double cost, double taxRate ) {

  return cost * taxRate / 100.0;

}

static double tax( double cost ) {

  return tax( cost, 19.0 );   // statt cost * 19.0 / 100;

}

 

2.7.13    Rekursive Methoden * 

Wir wollen den Einstieg in die Rekursion mit einem kurzen Beispiel beginnen. Auf dem Weg durch den Wald begegnet uns eine Fee (engl. fairy). Sie sagt zu uns: »Du hast drei Wünsche frei.« Tolle Situation. Um das ganze Unglück aus der Welt zu räumen, entscheiden wir uns nicht für eine egozentrische Wunscherfüllung, sondern für die sozialistische: »Ich möchte Frieden für alle, Gesundheit und Wohlstand für jeden.« Und schwups, so war es geschehen, und alle lebten glücklich, bis …

Einige Leser werden vielleicht die Hand vor den Kopf schlagen und sagen: »Quatsch! Selbstgießende Blumen, das letzte Ü-Ei in der Sammlung und einen Lebenspartner, der die Trägheit des Morgens duldet.« Glücklicherweise können wir das Dilemma mit der Rekursion lösen. Die Idee ist einfach – und in unseren Träumen schon erprobt –, sie besteht nämlich darin, den letzten Wunsch als »Noch mal drei Wünsche frei« zu formulieren.

static void fairy() {

  wish();

  wish();

  fairy();

}

Durch den dauernden Aufruf der fairy()-Methode haben wir unendlich viele Wünsche frei. Rekursion ist also das Aufrufen der eigenen Methode, in der wir uns befinden. Dies kann auch über einen Umweg funktionieren. Das nennt sich dann nicht mehr direkte Rekursion, sondern indirekte Rekursion. Sie ist ein alltägliches Phänomen, das wir auch von der Rückkopplung Mikrofon/Lautsprecher oder vom Blick mit einem Spiegel in den Spiegel kennen.

Unendliche Rekursionen

Wir müssen nun die Fantasieprogramme (deren Laufzeit und Speicherbedarf auch sehr schwer zu berechnen sind) gegen Java-Methoden austauschen.

static void down( int n ) {

  System.out.print( n + ", " );

  down( n - 1 );

}

Rufen wir down(10) auf, dann wird die Zahl 10 auf dem Bildschirm ausgegeben und anschließend down(9) aufgerufen. Führen wir das Beispiel fort, so ergibt sich eine endlose Ausgabe, die so beginnt und die irgendwann mit einem StackOverflowError abbricht:

10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, –1, –2, …

Abbildung 2.12    Steht der Cursor auf einem Methodenaufruf, so markiert Eclipse automatisch alle gleichen anderen Aufrufe oder die Deklaration der Methode.

Abbruch der Rekursion

An dieser Stelle erkennen wir, dass Rekursion prinzipiell etwas Unendliches ist. Für Programme ist dies aber ungünstig. Wir müssen daher ähnlich wie bei Schleifen eine Abbruchbedingung formulieren und dann keinen Rekursionsaufruf mehr starten. Die Abbruchbedingung sieht so aus, dass eine Fallunterscheidung das Argument prüft und mit return die Abarbeitung beendet:

Listing 2.39    src/main/java/Recursion.java, down1()

static void down1( int n ) {

  if ( n <= 0 )              // Rekursionsende

    return;



  System.out.print( n + ", " );

  down1( n - 1 );

}

Die statische down1(int)-Methode ruft jetzt nur noch so lange down1(n – 1) auf, wie das n größer null ist. Das ist die Abbruchbedingung einer Rekursion.

Unterschiedliche Rekursionsformen

Ein Kennzeichen der bisherigen Programme war, dass nach dem Aufruf der Rekursion keine Anweisung stand, sondern die Methode mit dem Aufruf beendet wurde. Diese Rekursionsform nennt sich Endrekursion. Diese Form ist verhältnismäßig einfach zu verstehen. Schwieriger sind Rekursionen, bei denen hinter dem Methodenaufruf Anweisungen stehen. Betrachten wir folgende Methoden, von denen die erste bekannt und die zweite neu ist:

Listing 2.40    src/main/java/Recursion.java, down1() und down2()

static void down1( int n ) {

  if ( n <= 0 )   // Rekursionsende

    return;



  System.out.print( n + ", " );



  down1( n - 1 );

}



static void down2( int n ) {

  if ( n <= 0 )   // Rekursionsende

    return;



  down2( n - 1 );



  System.out.print( n + ", " );

}

Der Unterschied besteht darin, dass down1(int) zuerst die Zahl n ausgibt und anschließend rekursiv down1(int) aufruft. Die Methode down2(int) steigt jedoch erst immer tiefer ab, und die Rekursion muss beendet sein, bis es zum ersten print(…) kommt. Daher gibt die statische Methode down2(int) im Gegensatz zu down1(int) die Zahlen in aufsteigender Reihenfolge aus:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10,

Dies ist einleuchtend, wenn wir die Ablaufreihenfolge betrachten. Beim Aufruf down2(10) ist der Vergleich von n mit null falsch, also wird ohne Ausgabe wieder down2(9) aufgerufen. Ohne Ausgabe deshalb, da print(…) ja erst nach dem Methodenaufruf steht. Es geht rekursiv tiefer, bis n gleich null ist. Dann endet die letzte Methode mit return, und die Ausgabe wird nach dem down2(int), dem Aufrufer, fortgeführt. Dort ist print(…) die nächste Anweisung. Da wir nun noch tief verschachtelt stecken, gibt print(n) die Zahl 1 aus. Dann ist die Methode down2(int) wieder beendet (ein unsichtbares, nicht direkt geschriebenes return), und sie springt zum Aufrufer zurück. Das ist wieder die Methode down2(int), aber mit der Belegung n = 2. Das geht so weiter, bis das Programm zurück zum Aufrufer kommt, der down(10) aufgerufen hat, zum Beispiel der statischen main(…)-Methode. Der Trick bei der Sache besteht nun darin, dass jede Methode ihre eigene lokale Variable besitzt.

  Die Tastenkombination (Strg)+(Alt)+(H) zeigt die Aufrufhierarchie an. So ist zu sehen, wer eine Methode aufruft. In den Aufrufen von down2(int) tauchen also wiederum wegen des rekursiven Aufrufs down2(int) sowie main(…) auf.

Rekursion und der Stack sowie die Gefahr eines StackOverflowErrors *

Am Beispiel haben wir gesehen, dass der Aufruf von down2(10) zum Aufruf von down2(9) führt. Und down2(10) kann erst dann beendet werden, wenn down2(9) komplett abgearbeitet wurde. down2(10) ist sozusagen so lange »offen«, bis der Schwanz von untergeordneten Aufrufen beendet ist. Nun muss sich die Laufzeitumgebung natürlich bei einem Methodenaufruf merken, wo es nach dem Methodenaufruf weitergeht. Dazu nutzt sie den Stack. Beim Aufruf von down2(9) etwa wird der Stack mit der Rücksprungadresse gefüllt, die zum Kontext von down2(10) zurückführt. In jedem Kontext gibt es auch wieder die alten lokalen Variablen.

Gibt es bei Rekursionen keine Abbruchbedingung, so kommen immer mehr Rücksprungadressen auf den Stapel, bis der Stapel keinen Platz mehr hat. Dann erzeugt die JVM zur Laufzeit ein java.lang.StackOverflowError, und das Programm (der Thread) bricht ab. In der Regel deutet der StackOverflowError auf einen Programmierfehler hin, es gibt aber Programme, die einen wirklich großen Stack benötigen und für die die gewöhnliche Stack-Größe einfach zu klein ist.

Stack-Größen ändern *

Die Oracle-JVM nutzt für unterschiedliche Betriebssysteme unterschiedliche Stack-Größen. Die Stack-Größe lässt sich über einen JVM-Schalter[ 102 ](https://docs.oracle.com/en/java/javase/13/docs/specs/man/java.html) ändern, der -Xss:n heißt (oder in etwas längerer Schreibweise -XX:ThreadStackSize=n). Um die Stack-Größe auf 2 MiB (2.048 KiB) zu setzen, schreiben wir:

$ java -Xss:2048 MyApplication

Die Stack-Größe gilt damit für alle Threads in der JVM, was natürlich bei großen Stacks und vielen Threads zu einem Speicherproblem führen kann. Umgekehrt lässt sich auch Speicher einsparen, wenn das System sehr viele Threads nutzt und die Stack-Größe verringert wird.

Keine Optimierung von Endrekursion *

Eine Endrekursion (engl. tail call recursion) ist eine Besonderheit bei Methoden, da sie mit einem rekursiven Aufruf enden. Zum Einstieg: Ist die bekannte rekursive Implementierung der Fakultät endrekursiv?

int factorial( int n ) {

  if ( n <= 0 ) return 1;

  return n * factorial( n - 1 );

}

Zwar sieht es optisch so aus, als ob factorial(int) mit einem Methodenaufruf an factorial(…) endet, doch findet hier keine Endrekursion statt, da nach dem Methodenaufruf noch eine Multiplikation folgt. Wenn man den Code etwas anders schreibt, ist das besser zu erkennen:

int factorial( int n ) {

  if ( n <= 0 ) return 1;

  int fac = factorial( n - 1 );

  return n * fac;

}

Die Berechnung der Fakultät lässt sich aber auch so umschreiben, dass tatsächlich eine Endrekursion stattfindet, und zwar durch Einführung eines Containers für Zwischenergebnisse, genannt Akkumulator:

int factorial( int n ) {

  return factorialTailrec( n, 1 );

}

private int factorialTailrec( int n, int accumulator ) {

  if ( n <= 0 ) return accumulator;

  return factorialTailrec( n - 1, n * accumulator );

}

Die umgeschriebene Version büßt gegenüber der ursprünglichen Version an Schönheit ein. Doch endrekursive Aufrufe sind attraktiv, da eine schlaue Übersetzungseinheit sie so optimieren kann, dass der rekursive Methodenaufruf durch einen Sprung ersetzt wird. In der Java-Sprache haben wir keine direkten Sprünge, doch im Bytecode schon, sodass die Basis der Optimierung im Grunde so aussehen kann:

private int factorialTailrec( int n, int accumulator ) {

start:

  if ( n <= 0 ) return accumulator;

  accumulator *= n;

  n--;

  goto start;

}

Die Rekursion ist durch eine ordinäre Schleife ersetzt, was Stack einspart und eine sehr gute Performance ergibt.

In funktionalen Programmen ergeben sich eher Situationen, in denen Endrekursion vorkommt, sodass es attraktiv ist, diese zu optimieren. Die Standard-JVM kann das bisher nicht, weil Java traditionell keine funktionale Programmiersprache ist und Endrekursion eher selten vorkommt. Zwar wird die Optimierung von Endrekursion (engl. tail call optimization, kurz TCO) immer wieder diskutiert und auch schon in Prototypen ausprobiert, aber nie von der Oracle-JVM implementiert. Für Entwickler heißt das, rekursive Aufrufe nicht in endrekursive Varianten umzuschreiben, da sie sowieso nicht optimiert werden und nur unleserlicher würden. Bei großen Datenvolumen, sprich Stack-Tiefe, ist es besser, auf eine nichtrekursive iterative Version umzustellen. Im Fall von factorialTailrec(...) kann dies so aussehen:

private int factorialTailrec( int n, int accumulator ) {

  while ( n > 0 ) {

    accumulator *= n;

    n--;

  }

  return accumulator;

}

 

2.7.14    Die Türme von Hanoi * 

Die Legende der Türme von Hanoi soll erstmalig von Ed Lucas in einem Artikel in der französischen Zeitschrift »Cosmo« im Jahre 1890 veröffentlicht worden sein.[ 103 ](Wir halten uns hier an eine Überlieferung von C. H. A. Koster aus dem Buch »Top-down Programming with Elan« von Ellis Horwood (Verlag Ellis Horwood Ltd, ISBN 0139249370, 1987). ) Der Legende nach standen vor langer Zeit im Tempel von Hanoi drei Säulen. Die erste war aus Kupfer, die zweite aus Silber und die dritte aus Gold. Auf der Kupfersäule waren einhundert Scheiben aufgestapelt. Die Scheiben hatten in der Mitte ein Loch und waren aus Porphyr[ 104 ](Gestein vulkanischen Ursprungs. Besondere Eigenschaften von Porphyr sind: hohe Bruchfestigkeit, hohe Beständigkeit gegen physikalisch-chemische Wirkstoffe und hohe Wälz- und Gleitreibung. ). Die Scheibe mit dem größten Umfang lag unten, und alle kleiner werdenden Scheiben lagen obenauf. Ein alter Mönch stellte sich die Aufgabe, den Turm der Scheiben von der Kupfersäule zur Goldsäule zu bewegen. In einem Schritt sollte aber nur eine Scheibe bewegt werden, und zudem war die Bedingung, dass eine größere Scheibe niemals auf eine kleinere bewegt werden durfte. Der Mönch erkannte schnell, dass er die Silbersäule nutzen musste; er setzte sich an einen Tisch, machte einen Plan, überlegte und kam zu einer Entscheidung. Er konnte sein Problem in drei Schritten lösen. Am nächsten Tag schlug der Mönch die Lösung an die Tempeltür:

• Falls der Turm aus mehr als einer Scheibe besteht, bitte deinen ältesten Schüler, einen Turm von (N – 1) Scheiben von der ersten zur dritten Säule unter Verwendung der zweiten Säule umzusetzen.

• Trage selbst die erste Scheibe von einer zur anderen Säule.

• Falls der Turm aus mehr als einer Scheibe besteht, bitte deinen ältesten Schüler, einen Turm aus (N – 1) Scheiben von der dritten zu der anderen Säule unter Verwendung der ersten Säule zu transportieren.

Und so rief der alte Mönch seinen ältesten Schüler zu sich und trug ihm auf, den Turm aus 99 Scheiben von der Kupfersäule zur Goldsäule unter Verwendung der Silbersäule umzuschichten und ihm den Vollzug zu melden. Nach der Legende würde das Ende der Welt nahe sein, bis der Mönch seine Arbeit beendet hätte. Nun, so weit die Geschichte. Wollen wir den Algorithmus zur Umschichtung der Porphyrscheiben in Java programmieren, so ist eine rekursive Lösung recht einfach. Werfen wir einen Blick auf das folgende Programm, das die Umschichtungen über die drei Pflöcke (engl. pegs) vornimmt:

Listing 2.41    src/main/java/TowerOfHanoi.java

class TowerOfHanoi {



 static void move( int n, String fromPeg, String toPeg, String usingPeg ) {



  if ( n > 1 ) {

   move( n - 1, fromPeg, usingPeg, toPeg );

   System.out.printf( "Bewege Scheibe %d von der %s zur %s.%n", n, fromPeg, toPeg );

   move( n - 1, usingPeg, toPeg, fromPeg );

  }

  else

   System.out.printf( "Bewege Scheibe %d von der %s zur %s.%n", n, fromPeg, toPeg );

 }



 public static void main( String[] args ) {

   move( 4, "Kupfersäule", "Goldsäule", "Silbersäule" );

 }

}

Starten wir das Programm mit vier Scheiben, so bekommen wir folgende Ausgabe:

Bewege Scheibe 1 von der Kupfersäule zur Silbersäule.

Bewege Scheibe 2 von der Kupfersäule zur Goldsäule.

Bewege Scheibe 1 von der Silbersäule zur Goldsäule.

Bewege Scheibe 3 von der Kupfersäule zur Silbersäule.

Bewege Scheibe 1 von der Goldsäule zur Kupfersäule.

Bewege Scheibe 2 von der Goldsäule zur Silbersäule.

Bewege Scheibe 1 von der Kupfersäule zur Silbersäule.

Bewege Scheibe 4 von der Kupfersäule zur Goldsäule.

Bewege Scheibe 1 von der Silbersäule zur Goldsäule.

Bewege Scheibe 2 von der Silbersäule zur Kupfersäule.

Bewege Scheibe 1 von der Goldsäule zur Kupfersäule.

Bewege Scheibe 3 von der Silbersäule zur Goldsäule.

Bewege Scheibe 1 von der Kupfersäule zur Silbersäule.

Bewege Scheibe 2 von der Kupfersäule zur Goldsäule.

Bewege Scheibe 1 von der Silbersäule zur Goldsäule.

Schon bei vier Scheiben haben wir 15 Bewegungen. Selbst wenn unser Prozessor mit vielen Millionen Operationen pro Sekunde arbeitet, benötigt ein Computer für die Abarbeitung von 100 Scheiben Tausende geologischer Erdzeitalter. An diesem Beispiel wird eines deutlich: Viele Dinge sind im Prinzip berechenbar, nur praktisch ist so ein Algorithmus nicht.