Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil6 Eigene Klassen schreiben
Pfeil6.1 Eigene Klassen mit Eigenschaften deklarieren
Pfeil6.1.1 Attribute deklarieren
Pfeil6.1.2 Methoden deklarieren
Pfeil6.1.3 Verdeckte (shadowed) Variablen
Pfeil6.1.4 Die this-Referenz
Pfeil6.2 Privatsphäre und Sichtbarkeit
Pfeil6.2.1 Für die Öffentlichkeit: public
Pfeil6.2.2 Kein Public Viewing – Passwörter sind privat
Pfeil6.2.3 Wieso nicht freie Methoden und Variablen für alle?
Pfeil6.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht *
Pfeil6.2.5 Zugriffsmethoden für Attribute deklarieren
Pfeil6.2.6 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil6.2.7 Paketsichtbar
Pfeil6.2.8 Zusammenfassung zur Sichtbarkeit
Pfeil6.3 Eine für alle – statische Methoden und statische Attribute
Pfeil6.3.1 Warum statische Eigenschaften sinnvoll sind
Pfeil6.3.2 Statische Eigenschaften mit static
Pfeil6.3.3 Statische Eigenschaften über Referenzen nutzen? *
Pfeil6.3.4 Warum die Groß- und Kleinschreibung wichtig ist *
Pfeil6.3.5 Statische Variablen zum Datenaustausch *
Pfeil6.3.6 Statische Eigenschaften und Objekteigenschaften *
Pfeil6.4 Konstanten und Aufzählungen
Pfeil6.4.1 Konstanten über statische finale Variablen
Pfeil6.4.2 Typunsichere Aufzählungen
Pfeil6.4.3 Aufzählungstypen: typsichere Aufzählungen mit enum
Pfeil6.5 Objekte anlegen und zerstören
Pfeil6.5.1 Konstruktoren schreiben
Pfeil6.5.2 Verwandtschaft von Methode und Konstruktor
Pfeil6.5.3 Der Standard-Konstruktor (default constructor)
Pfeil6.5.4 Parametrisierte und überladene Konstruktoren
Pfeil6.5.5 Copy-Konstruktor
Pfeil6.5.6 Einen anderen Konstruktor der gleichen Klasse mit this(…) aufrufen
Pfeil6.5.7 Immutable-Objekte und Wither-Methoden
Pfeil6.5.8 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil6.6 Klassen- und Objektinitialisierung *
Pfeil6.6.1 Initialisierung von Objektvariablen
Pfeil6.6.2 Statische Blöcke als Klasseninitialisierer
Pfeil6.6.3 Initialisierung von Klassenvariablen
Pfeil6.6.4 Eincompilierte Belegungen der Klassenvariablen
Pfeil6.6.5 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil6.6.6 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil6.7 Zum Weiterlesen
 

Zum Seitenanfang

6.4    Konstanten und Aufzählungen Zur vorigen ÜberschriftZur nächsten Überschrift

In Programmen gibt es Variablen, die sich ändern (wie zum Beispiel ein Schleifenzähler), aber auch andere, die sich beim Ablauf eines Programms nicht ändern. Dazu gehören etwa die Startzeit der Tagesschau oder die Maße einer DIN-A4-Seite. Die Werte sollten nicht wiederholt im Quellcode stehen, sondern über ihre Namen angesprochen werden. Dazu werden Variablen deklariert, denen genau der konstante Wert zugewiesen wird; die Konstanten heißen dann symbolische Konstanten.

In Java gibt es zur Deklaration von Konstanten zwei Möglichkeiten:

  • Selbst definierte öffentliche statische finale Variablen nehmen konstante Werte auf.

  • Aufzählungen über ein enum (die intern aber auch nur öffentliche finale statische Werte sind)

 

Zum Seitenanfang

6.4.1    Konstanten über statische finale Variablen Zur vorigen ÜberschriftZur nächsten Überschrift

Statische Variablen werden auch verwendet, um symbolische Konstanten zu deklarieren. Damit die Variablen unveränderlich bleiben, gesellt sich der Modifizierer final hinzu. Dem Compiler wird auf diese Weise mitgeteilt, dass dieser Variablen nur einmal ein Wert zugewiesen werden darf. Für Variablen bedeutet dies: Es sind Konstanten; jeder spätere Schreibzugriff wäre ein Fehler. In der Regel sind die Konstanten öffentlich, aber natürlich können sie auch privat sein, wenn sie nur die Klasse etwas angehen.

Konstante Werte haben wir schon bei GameUtils eingesetzt:

Listing 6.26    GameUtils, Ausschnitt

public class GameUtils {

...

public static final int MAX_ID_LEN = 20 /* chars */;

...

}

Da im Quellcode das Vorkommen von Zahlen wie der 20 undurchsichtig wäre, sind symbolische Namen zwingend. Stehen dennoch Zahlen ohne offensichtliche Bedeutung im Quellcode, so werden sie magische Zahlen (engl. magic numbers) genannt. Es gilt, diese Werte in Konstanten zu fassen und sinnvoll zu benennen.

[+]  Tipp

Es ist eine gute Idee, die Namen von Konstanten durchgehend großzuschreiben, um ihre Bedeutung hervorzuheben.

Der Zugriff auf die Variablen sieht genauso aus wie ein Zugriff auf andere statische Variablen.

[zB]  Beispiel

Greife auf Konstanten zurück:

System.out.println( Math.PI );

int len = GameUtils.MAX_ID_LEN;

if ( s.length() > GameUtils.MAX_ID_LEN )

System.out.println( "Zu lang!" );
 

Zum Seitenanfang

6.4.2    Typunsichere Aufzählungen Zur vorigen ÜberschriftZur nächsten Überschrift

Konstanten sind eine wertvolle Möglichkeit, um den Quellcode aussagekräftiger und klarer zu gestalten, was wichtig ist, denn Quellcode wird öfter gelesen als geschrieben. Oftmals finden sich Konstanten für mathematische Konstanten oder Größenbeschränkungen.

Eine besondere Form bilden Konstanten, wenn sie als Elemente von Aufzählungen verwendet werden. Aufzählungen erinnern an abgeschlossene Mengen, so wie:

  • Tage der Woche (Montag, Dienstag …)

  • Monate eines Jahrs (Januar, Februar …)

  • Font-Stile (fett, kursiv …)

  • vordefinierte Linienmuster (durchgezogen, gestrichelt …)

Die Tage der Woche und auch die Monate des Jahres werden zum Beispiel von der Klasse java. util.Calendar über öffentliche statische int-Konstanten angeboten.

[zB]  Beispiel

Die Frau wird im Juni schwanger. Wann müssen Windeln gekauft werden?

int month = Calendar.JUNE;

int conception = (month + 9) % 12;

System.out.println( conception ); // 2

Soll eine Klasse Materials zum Beispiel Konstanten für die Beschaffenheit eines Materials deklarieren, kann das so aussehen:

Listing 6.27    src/main/java/com/tutego/insel/oop/Materials.java

public class Materials {

private Materials() { } // Privater Konstruktor

public static final int SOFT = 0;

public static final int HARD = 1;

public static final int DRY = 2;

public static final int WET = 3;

public static final int SMOOTH = 4;

public static final int ROUGH = SMOOTH + 1;

}

Für ihre Belegungen ist es günstig, die Konstanten relativ zum Vorgänger zu wählen, um das Einfügen in der Mitte zu vereinfachen. Das sehen wir bei der letzten Variablen, ROUGH.

UML-Diagramm der Klasse »Materials« mit Konstanten

Abbildung 6.11    UML-Diagramm der Klasse »Materials« mit Konstanten

Problem mit dem Datentyp int als Konstantentyp

Einfache Konstantentypen – wie bei uns int – bringen den Nachteil mit sich, dass die Konstanten nicht unbedingt von jedem angewendet werden müssen und ein Programmierer die Zahlen oder Zeichenketten eventuell direkt einsetzt. Das ist in dem Moment problematisch, sobald sich die Belegung einer Konstanten einmal ändert. Bei einer Konstanten wie Math.PI wird das nicht passieren, aber die Maximallänge eines Strings kann durchaus einmal angepasst werden, genauso wie der Materialtyp, wenn zum Beispiel ein neues Material eingeschoben wird.

Im Idealfall haben Aufzählungen einen eigenen Typ. Sind sie »nur« vom Typ int, führt das leicht zu Fehlern. Die Font-Klasse der Java-API illustriert das Problem: Die Parametertypen beim Konstruktor sind: Font(String, int, int). Versagt unser Gedächtnis, für was welches int steht, heißt es im Aufruf vielleicht:

Font f = new Font( "Dialog", 12, Font.BOLD );

Leider ist dies falsch, denn die Argumente für die Größe und den Schriftstil sind vertauscht: Es müsste new Font("Dialog", Font.BOLD, 12) heißen, denn das erste int steht für den Stil und das zweite int für die Größe. Font.BOLD ist eine int-Konstante.

Konstanten sind nur Namen für Werte eines frei zugänglichen Grundtyps (hier int), und nur die Variablenbelegung, also der Wert, wird an den Konstruktor übergeben. Niemand kann verbieten, dass die Werte direkt eingetragen werden. Das führt dann zu Fehlern wie im oberen Fall, in dem 12 die Ganzzahl für den Schriftstil ist, obwohl es dafür nur die Werte 0, 1, 2 geben sollte. Mit Zeichenketten als Werten der Konstanten kommen wir der Lösung auch nicht näher, wohl aber, wenn der Typ kein int wäre, sondern ein Objekttyp, denn der würde sich vom int unterscheiden.

[»]  Hinweis

Ganzzahlen haben aber durchaus ihren Vorteil, wenn es verknüpfte Aufzählungen gibt, also etwa ein hartes und ein raues Material. Das lässt sich durch Materials.HARD + Materials.ROUGH darstellen – was aber nur dann gut funktioniert, wenn jede Konstante ein Bit im Wort einnimmt, wenn also die Werte der Konstanten 1, 2, 4, 8, 16 … lauten.

Eine gute Möglichkeit, von Ganzzahlen wegzukommen, besteht darin, Objekte einer Klasse als Konstanten einzusetzen. Hier muss nicht auf eigene Klassendeklarationen zurückgegriffen werden, sondern Java bietet ein eigenes Sprachmittel.

 

Zum Seitenanfang

6.4.3    Aufzählungstypen: typsichere Aufzählungen mit enum Zur vorigen ÜberschriftZur nächsten Überschrift

Damit Konstanten von Aufzählungen einen eigenen Typ bekommen und nicht mehr Ganzzahlen oder Strings sind, bietet Java ein Sprachkonstrukt über das Schlüsselwort enum. Die Schreibweise für Aufzählungen erinnert ein wenig an die Deklaration von Klassen und Variablen, nur dass das Schlüsselwort enum statt class gebraucht wird und dass die Variablen automatisch statisch und öffentlich sind und kein Typ angegeben ist. Aufzählungen für Wochentage sind ein gutes Beispiel:

Listing 6.28    src/main/java/com/tutego/weekday/Weekday.java, Weekday

public enum Weekday {

MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY

}

Weekday ist ein Aufzählungstyp. Die Konstantennamen werden wie üblich großgeschrieben – so wie auch statische Variablen, die als Konstanten benutzt werden, großgeschrieben werden.

Eine Aufzählung in UML wird über den Stereotyp ausgedrückt.

Abbildung 6.12    Eine Aufzählung in UML wird über den Stereotyp ausgedrückt.

Aufzählungen nutzen

Um zu verstehen, wie sich Aufzählungstypen nutzen lassen, ist es hilfreich, zu wissen, wie der Compiler sie umsetzt. Intern erstellt der Compiler eine normale Klasse, in unserem Fall Weekday. Alle Aufzählungselemente sind statische Variablen (Konstanten) vom Typ der Aufzählung:

public class Weekday {

public static final Weekday MONDAY = new Weekday( ... );

public static final Weekday TUESDAY = new Weekday( ... );

...

}

Beim Laden der Klasse werden sieben Weekday-Objekte intern angelegt und die statischen Variablen initialisiert. Jetzt ist es einfach, diese Aufzählungen zu nutzen, da sie wie jede andere statische Variable angesprochen werden:

Weekday day = Weekday.SATURDAY;

Hinter den Aufzählungen stehen Objekte, die sich – wie alle anderen – weiterverarbeiten lassen.

if ( day == Weekday.MONDAY )

System.out.println( "'I hate Mondays' (Garfield)" );

Auch implementieren die enum-Konstanten die toString()-Methode, die den Namen der Konstanten liefert.

[»]  Geschichte

Sun reservierte zu Beginn der Entwicklung von Java diverse Schlüsselwörter, aber enum war nicht seit Beginn dabei. Als dann in Java 5 plötzlich ein neues Schlüsselwort hinzukam, mussten Entwickler viel Quellcode anpassen und Variablennamen ändern, denn für den Variablentyp java.util.Enumeration war gern der Variablenname enum gewählt worden.

Aufzählungsvergleiche mit ==

Wie die Umsetzung der Aufzählungstypen zeigt, wird für jede Konstante ein Objekt konstruiert, und das sind sogenannte Singletons, also Objekte, die nur einmal erzeugt werden. Eigene neue Aufzählungsobjekte können wir nicht aufbauen, da die Klasse nur einen privaten Konstruktor deklariert. Der Zugriff auf dieses Objekt ist wie ein Zugriff auf eine statische Variable. Der Vergleich zweier Konstanten läuft somit auf den Vergleich von statischen Referenzvariablen hinaus, wofür der Vergleich mit == völlig korrekt ist. Ein equals(…) ist nicht nötig.

[zB]  Beispiel

Eine Methode soll entscheiden, ob ein Tag das Wochenende einläutet:

public static boolean isWeekend( Weekday day ) {

return day == Weekday.SATURDAY || day == Weekday.SUNDAY;

}

enum-Konstanten in switch

enum-Konstanten sind in switch-Anweisungen möglich. Das ist möglich, da sie intern über eine Ganzzahl als Identifizierer verfügen, den der Compiler für die Aufzählung einsetzt. Das ist ein ähnliches Konzept, wie es der Compiler auch bei switch auf Strings verfolgt.

Initialisieren wir eine Variable vom Typ Weekday, und nutzen wir eine Fallunterscheidung mit der Aufzählung für einen Test auf das Wochenende:

Listing 6.29    src/main/java/WeekdayDemo.java, Ausschnitt main()

Weekday day = Weekday.MONDAY;

switch ( day ) {

case SATURDAY: // nicht Weekday.SATURDAY!

case SUNDAY: System.out.println( "Wochenende. Party!" );

}

Dass case Weekday.SATURDAY nicht möglich ist, erklärt sich dadurch, dass mit switch (day) schon der Typ Weekday über die Variable day bestimmt ist. Es ist nicht möglich, dass der Typ der switch-Variablen vom Typ der Variablen in case abweicht.

Referenzen vom Aufzählungstyp können null sein

Dass die Aufzählungen nur Objekte sind, hat eine wichtige Konsequenz. Blicken wir zunächst auf eine Variablendeklaration vom Typ eines enum, die mit einem Wochentag initialisiert ist:

Weekday day = Weekday.MONDAY;

Die Variable day speichert einen Verweis auf das Weekday.MONDAY-Objekt. Das Unschöne an Referenzvariablen ist allerdings, dass sie auch mit null belegt werden können, was so gesehen kein Element der Aufzählung ist:

Weekday day = null;

Wenn solch eine null-Referenz in einem switch landet, gibt es eine NullPointerException, da versteckt im switch ein Zugriff auf die im Enum-Objekt gespeicherte Ordinalzahl stattfindet.

Methoden, die Elemente einer Aufzählung – also Objektverweise – entgegennehmen, sollten im Allgemeinen auf null testen und eine Ausnahme auslösen, um diesen fehlerhaften Teil anzuzeigen; das kann die gegebene Hilfsmethode Objects.requireNonNull(…) übernehmen:

public void setWeekday( Weekday day ) {

this.day = Objects.requireNonNull( day, "Weekday day darf nicht null sein" );

}

Aufzählungstypen als geschachtelten Typ deklarieren *

Es gibt »normale« Aufzählungen, die an normale Klassen erinnern, und auch »geschachtelte« Aufzählungen, die in einen anderen Typ hineingesetzt werden. Mit anderen Worten: Weekday kann auch innerhalb einer anderen Klasse bzw. anderen Schnittstelle deklariert werden. Ist die geschachtelte Aufzählung öffentlich, kann jeder sie nutzen. Sie folgt aber den gleichen Sichtbarkeiten wie Klassen, da Aufzählungen ja nichts anderes als Klassen sind, die der Compiler generiert. Aufzählungen innerhalb von Typen sind immer implizit statisch, das Schlüsselwort static ist also nicht nötig.

[zB]  Beispiel

Beide Deklarationen sind identisch, die ohne static ist vorzuziehen:

class Point { enum Color { RED, BLUE, GREEN } }          // Üblich

versus

class Point { static enum Color { RED, BLUE, GREEN } }   // Unüblich

Statische Importe von Aufzählungen *

Die Aufzählung Weekday hatten wir in das Paket com.tutego.insel.weekday gesetzt. Um auf eine Konstante wie MONDAY zugreifen zu können, wollen wir unterschiedliche import-Varianten nutzen.

Import-Deklaration

Zugriff

import com.tutego.insel.weekday.Weekday;

Weekday.MONDAY

import com.tutego.insel.weekday.*;

Weekday.MONDAY

import static com.tutego.insel.weekday.insel. Weekday.*;

MONDAY

Tabelle 6.5    Welche Zugriffe sind mit welchen »import«-Deklarationen möglich?

Nehmen wir im Paket als zweites Beispiel eine geschachtelte Aufzählung der Klasse Week hinzu:

Listing 6.30    src/main/java/com/tutego/insel/weekday/Week.java

package com.tutego.insel.weekday;



public class Week {

public enum Weekday {

MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY

}

}

Import-Deklaration

Zugriff

import com.tutego.insel.weekday.Week;

Week.Weekday.MONDAY

import com.tutego.insel.weekday.Week.Weekday;

Weekday.MONDAY

import static com.tutego.insel.weekday.Week.Weekday.*

MONDAY

Tabelle 6.6    Welche Zugriffe sind mit welchen »import«-Deklarationen möglich?

Standardmethoden der Aufzählungstypen *

Die erzeugten Enum-Objekte bekommen standardmäßig eine Reihe von zusätzlichen Eigenschaften. Wir überschreiben sinnvoll toString(), hashCode() und equals(…) aus Object und implementieren zusätzlich Serializable und Comparable[ 150 ](Die Ordnung der Konstanten ist die Reihenfolge, in der sie geschrieben sind. ), aber nicht Cloneable, da Aufzählungsobjekte nicht geklont werden können. Die Methode toString() liefert den Namen der Konstanten, sodass Weekday.SUNDAY.toString().equals("SUNDAY") wahr ist. Zusätzlich erbt jedes Aufzählungsobjekt von der Spezialklasse Enum, die in Abschnitt 10.7, »Die Spezial-Oberklasse Enum«, näher erklärt wird.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern