Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort
Download: - ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / Java-Insel | vor >>
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel (8. Aufl.) 8., aktual. Auflage, geb., mit DVD 1.475 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1371-4 |
| 9 Generics, innere Klassen
|  | 9.1 Generische Datentypen
|  |  | 9.1.1 Einfache Klassenschablonen
|  |  | 9.1.2 Einfache Methodenschablonen
|  |  | 9.1.3 Umsetzen der Generics, Typlöschung und Raw-Types
|  |  | 9.1.4 Generics und Arrays
|  |  | 9.1.5 Einschränken der Typen
|  |  | 9.1.6 Generics und Vererbung, Invarianz
|  |  | 9.1.7 Wildcards
|  | 9.2 Geschachtelte (innere) Klassen, Schnittstellen, Aufzählungen
|  |  | 9.2.1 Statische innere Klassen und Schnittstellen
|  |  | 9.2.2 Mitglieds- oder Elementklassen
|  |  | 9.2.3 Lokale Klassen
|  |  | 9.2.4 Anonyme innere Klassen
|  |  | 9.2.5 this und Vererbung
Zu mancher richtigen Entscheidung kam es nur, weil der Weg zur falschen gerade nicht frei war. Hans Krailsheimer (1888–1958) # 9 Generics, innere Klassen ## 9.1 Generische Datentypen Nehmen wir an, wir wollten einen Container für eine einfache Zahl implementieren; der Datentyp soll int sein:
    class IntBox
    {
      private int val;

      void setValue( int val )
      {
        this.val = val;
      }

      int getValue()
      {
        return val;
      }
    }
Es gibt einen automatischen Standard-Konstruktor, und mit setValue() können wir eine Zahl angeben und den Wert über die Zugriffsmethode auslesen. Was ist, wenn wir eine zweite Box für Strings implementieren wollen? Wir müssten Quellcode duplizieren und überall, wo int steht, den Datentyp String einsetzen:
    class StringBox
    {
      private String val;

      void setValue( String val )
      {
        this.val = val;
      }

      String getValue()
      {
        return val;
      }
    }
In unserem Beispiel sind das drei Änderungen, aber der Rest des Gerüstes bleibt gleich. Für jeden neuen Datentyp muss eine neue Klasse her – die Logik bleibt die gleiche. Es gibt eine ganze Reihe von Beispielen, in denen Speicherstrukturen wie unsere Box nicht nur für einen Datentyp sinnvoll sind. Das gilt auch für Algorithmen, etwa einen, der Zahlen sortiert. Wenn zwei Zahlen größer oder kleiner sein können, muss ein Algorithmus lediglich diese Eigenschaft nutzen können, aber es wäre egal, ob die Zahlen von der Größe byte, short, int, long oder auch Gleitkommazahlen sind – der Algorithmus selbst ist davon nicht betroffen. Ein Algorithmus, der von einem Datentyp unabhängig programmiert werden kann, heißt generisch, und die Möglichkeit, in Java mit generischen Typen zu arbeiten, heißt Generics. [In C(++) werden diese Typen von Klassen parametrisierte Klassen oder Templates (Schablonen) genannt.] Leider funktioniert das Beispiel mit der IntBox in Java nicht, denn generische Typen können in Java nur Objekte sein, aber keine primitiven Datentypen. Das schränkt die Möglichkeiten zwar ein, doch weil es Autoboxing gibt, lässt sich damit leben. Die Implementierung der Java-Generics basiert auf einem Projekt namens Pizza. Später wurde aus Pizza GJ, und schließlich wurde dies zur Basis des Java Specification Request 14: »Add Generic Types To The Java Programming Language«. ### 9.1.1 Einfache Klassenschablonen Wenn wir die StringBox als Basis nehmen, haben wir bei der Übersetzung der IntBox in die StringBox drei Stellen gefunden, an denen wir den Typ ändern müssen. Wollen wir die Box in einen generischen Typ umbauen, so müssen wir an den drei Stellen, an denen der konkrete Typ String vorkam, einen Typ-Stellvertreter, eine so genannte Typ-Variable, einsetzen. Der Name der Typ-Variable muss in der Klassendeklaration angegeben werden, da es durchaus mehr als einen Stellvertreter geben kann. Die Syntax für die generische Typdefinition für unsere Box ist folgende: Listing 9.1 com/tutego/insel/generics/Box.java
    package com.tutego.insel.generics;

    class Box<T>
    {
      private T val;

      void setValue( T val )
      {
        this.val = val;
      }

      T getValue()
      {
        return val;
      }
    }
Anstelle des konkreten Typs String steht ein formaler Typ-Parameter, in unserem Fall ist das T – die Abkürzung ist oft T, das für Typ steht. Bei generischen Klassen steht die Angabe des Typnamens nur einmal zu Beginn der Klassendeklaration in spitzen Klammern hinter dem Klassennamen. Um die Box nutzen zu können, müssen wir sie mit einem speziellen Typ erzeugen, dem parametrisierten Typ. Er ist eine Instanziierung eines generischen Typs mit konkreten Typargumenten (etwa String oder Integer oder Point). Der konkrete Typ steht hinter dem Klassennamen in spitzen Klammern. Listing 9.2 com/tutego/insel/generics/GenericBoxExample1.java, Ausschnitt
    Box<String>  stringBox = new Box<String>();
    Box<Integer> intBox    = new Box<Integer>();
    Box<Point>   pointBox  = new Box<Point>();
Das Schöne daran ist, dass nun alle generischen Eigenschaften mit dem angegebenen Typ durchgeführt werden. Wenn wir etwa aus pointBox mit getValue() auf das Element zugreifen, ist es vom Typ Point:
    pointBox.setValue( new Point(1, 2) );
    double x = pointBox.getValue().getX();
### 9.1.2 Einfache Methodenschablonen Eine Klasse kann ganz normal ohne Generics deklariert werden, aber mit Methoden, die die Typen generisch vorschreiben. Das gilt für Objektmethoden und Klassenmethoden. Interessant ist dies für Utility-Klassen, die nur statische Funktionen anbieten, aber selbst nicht als Objekt vorliegen.
    class Util
    {
      public static <T> T random( T m, T n )
      {
        return Math.random() > 0.5 ? m : n;
      }
    }
Hier wird die Funktion random() auf einem beliebigen Typ deklariert; die Angabe von <T> beim Klassennamen entfällt und verschiebt sich auf die Deklaration der Methode. Die Benutzung kann ohne Angabe des Typs – aber doch überprüft – geschehen:
    String s = Util.random( "Essen", "Schlafen" );
Ersetzen wir einen der beiden Strings durch einen Wert vom Typ Integer, so wird der Compiler einen Fehler melden, da die beiden übergebenen Typen nicht übereinstimmen. ### 9.1.3 Umsetzen der Generics, Typlöschung und Raw-Types Es gibt zwei Realisierungsmöglichkeiten von generischen Datentypen: Heterogene Variante. Für jeden Typ (etwa String, Integer, Point) wird individueller Code erzeugt, also drei Klassen. Homogene Übersetzung. Für jede parametrisierte Klasse wird eine Klasse erzeugt, die anstelle des generischen Typs Object einsetzt. Für einen konkreten Typ werden Typanpassungen in die Anweisungen eingebaut. Java nutzt die homogene Übersetzung. #### Typlöschung Übersetzt der Java-Compiler die generischen Anwendungen, so löscht er dabei alle Typinformationen (engl. type erasure). Das ist zwar für die Laufzeitumgebung praktisch, weil sie nicht auf die Generics großartig angepasst werden muss, sonst aber stellt das ein riesiges Problem dar, weil dann die Typinformationen zur Laufzeit nicht vorhanden sind. Programmierer müssen das wissen, da zum Beispiel der instanceof-Operator so nicht funktioniert: Listing 9.3 com/tutego/insel/generics/GenericBoxExample2.java, Ausschnitt
    Box<String> stringBox = new Box<String>();

    boolean b1 =  stringBox instanceof Box<Number>;  // illegal generic type for instanceof
    boolean b2 =  stringBox instanceof Box<String>;  // illegal generic type for instanceof
Der Compiler meldet zu Recht einen Fehler – nicht nur eine Warnung –, weil es die Typen Box<String> und Box<Number> zur Laufzeit gar nicht gibt: Es sind nur typgelöschte Box-Objekte. Das zeigt auch das folgende Beispiel: Listing 9.4 com/tutego/insel/generics/GenericBoxExample2.java, Ausschnitt
    Box<String>  box1 = new Box<String>();
    Box<Integer> box2 = new Box<Integer>();
    System.out.println( box1.getClass() == box2.getClass() );     // true
Dass diese Informationen übrigens nicht vorliegen, wird auch damit begründet, dass die Laufzeit leiden könnte. Microsoft war das aber egal, dort besteht Generizität in der Common Language Runtime (CLR). Microsoft ist damit einen klaren Schritt voraus. #### Typanpassungen Ein mit Generics spezifizierter Typ lässt sich durch Typanpassung auf eine allgemeine Form bringen:
    List<Integer> list = new ArrayList<Integer>();
    List noGenericList = (List) list;
Bei der noGenericList prüft der Compiler natürlich gar keine Typen mehr, denn er hat sie ja »vergessen«. Eine Anweisung, die einen Nicht-Integer-Typ in die Liste einfügt, bringt keinen Fehler zur Übersetzungszeit, und so kann über die Hintertür ein falscher Typ in die Datenstruktur kommen:
    noGenericList.add( "Das macht man aber nicht" );
Die Generics bieten uns Möglichkeiten, den Quellcode sicherer zu machen. Wir sollten diese Sicherheit nicht durch ungetypte Schreibweisen kaputtmachen. #### Raw-Type Generische Klassen müssen nicht unbedingt parametrisiert werden; sie sind mit dem Datentyp Object weiterhin gültig. Das ist auch wichtig, da sonst viele parametrisierte neue Klassen nicht mehr mit altem Programmcode verwendet werden könnten. Listing 9.5 com/tutego/insel/generics/GenericBoxExample3.java, Ausschnitt
    Box stringBox = new Box<String>();
    Box pointBox  = new Box<Point>();
    Box objectBox = new Box();
Ein generischer Typ ohne Typargument heißt Raw-Type. In unserem Beispiel ist Box der Raw-Type von Box<T>. Ein Raw-Type besitzt die gleichen Eigenschaften wie ein generischer Typ, nur kann der Compiler ohne parametrisierten Typ die Typkonformität nicht mehr prüfen. Im ersten Fall liefert getValue() den korrekten Typ String, Analoges gilt für Point. Im letzten Fall liefert getValue() nur Object, da hier jeder Bezug zum Typ fehlt. Doch was ist eigentlich mit setValue()? Erinnern wir uns an die Deklaration:
    void setValue( T val )
    {
      this.val = val;
    }
Diese Methode ist so ausgelegt, dass sie ein Argument von mindestens dem Typ akzeptiert, mit dem sie parametrisiert wurde. Fehlt durch die Verwendung des Raw-Types der konkrete Typ, bleibt Object, und der Compiler gibt eine Warnung aus:
    objectBox.setValue( "Unsafe type operation: " +
        "Should not invoke the method setValue(T) of raw type Box. " +
        "References to generic type Box<T> should be parameterized" );
Der Hinweis besagt, die Box hätte typisiert werden müssen. Achten wir darauf nicht, kann das schnell zu Problemen führen:
    Box<String> stringBox2 = new Box<String>();
    Box         objectBox2 = stringBox2;
Der Compiler gibt keinen Fehler und auch keine Warnung aus. Die zweite Zeile ist allerdings hochgradig problematisch, denn über die nicht parametrisierte Objekt-Box können wir beliebige Objekte in die Box packen. Da aber objectBox2 in Wirklichkeit ein typgelöschter Verweis auf die stringBox2 ist, haben wir ein Typproblem:
    objectBox2.setValue( new java.util.Date() ); // Warnung vor
                                                 // der »Unsafe type operation«
    String s = stringBox2.getValue();
    System.out.println( stringBox2.getValue() );
Die letzten beiden Zeilen führen zur Laufzeit zu einer ClassCastException der Art:
    Exception in thread "main" java.lang.ClassCastException: java.util.Date
      at com.tutego.insel.generics.GenericBoxExample3.main(GenericBoxExample3.java:17)
### 9.1.4 Generics und Arrays Die Typlöschung ist der Grund dafür, das Arrays nicht so umgesetzt werden können, wie es sich der Entwickler denkt. [Bei Sun (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4888066) ist dafür ein Bug gelistet. Suns Antwort auf die Bitte lautet lapidar: »Some day, perhaps, but not now.«] Folgendes gibt einen Compilerfehler.
    class TwoBox<T>
    {
      private T[] array = new T[ 2 ];   // Cannot create a generic array of T
      T[] getArray() { return array; }
    }
Der Grund für diesen Fehler ist dann gut zu erkennen, wenn wir überlegen, zu welchem Programmcode die Typlöschung führen würde:
    class TwoBox
    {
      Object[] array = new Object[ 2 ];                      // (1)
      Object[] getArray() { return array; }
     }
Der Aufrufer würde nun die TwoBox parametrisiert verwenden wollen:
    TwoBox<String> twoStrings = new TwoBox<String>();
    String[] stringArray = twoStrings.getArray();
Denken wir an dieser Stelle wieder an die Typlöschung und an das, was der Compiler generiert:
    TwoBox twoStrings = new TwoBox();
    String[] stringArray = (String[]) twoStrings.getArray(); // (2)
Jetzt ist es auffällig: Während (1) ein Object-Array der Länge 2 aufbaut und auch getArray() dies als Object-Array nach außen gibt, castet (2) dieses Object-Array auf ein String-Array. Das geht aber nicht, denn diese beiden Typen sind nicht typkompatibel. Zwar kann natürlich ein Object-Array Strings referenzieren, aber das Feld selbst als Objekt ist eben ein Object[] und kein String[].
Hinweis Die Java-API bietet über Reflection eine Möglichkeit, Arrays eines Typs zu erzeugen:
    T[] array = (T[]) Array.newInstance( clazz, 2 );
Allerdings muss der Class-Typ clazz bekannt sein und müsste als zusätzlicher Parameter übergeben werden. Die Syntax T.class gibt einen Compilerfehler, denn über die Typ-löschung wäre das ja sowieso immer Object.class, was den gleichen Fehler wie vorher ergibt und kein Fortschritt wäre.
### 9.1.5 Einschränken der Typen Bei generischen Angaben können die Typen weiter eingeschränkt werden. Es kann vorgeschrieben werden, dass der Typ eine konkrete Schnittstelle implementieren muss. Unsere Deklaration von random() sah keine Einschränkungen vor, sodass zum Beispiel auch Folgendes möglich ist:
    Serializable s1 = new Serializable() { };
    Serializable s2 = new Point();
    Util.random( s1, s2 );
Da der Typ beliebig ist, können auch Objekte aufgenommen werden, die vielleicht wenig Sinn ergeben, wie unsere Klassen, die lediglich Serializable implementieren. #### Einschränkung mit extends Um dies zu vermeiden, kann der Typ bei der Deklaration eingeschränkt werden. Wollen wir nur Klassen, die CharSequence implementieren (also Zeichenfolgen wie String und StringBuffer/StringBuilder), so schreiben wir das in die Deklaration mit hinein:
    public static <T extends CharSequence> T random( T m, T n )
    {
      return Math.random() > 0.5 ? m : n;
    }
Jetzt wird der Compiler mit übergebenem Serializable einen Fehler melden. Einen Aufruf wie Util.random("Kino", "Lesen"); lässt der Compiler korrekterweise durch. Sinnvoll ist diese Einschränkung, wenn es Schnittstellen sind, die Methoden vorschreiben, da sich diese direkt nutzen lassen. Das ist logisch, denn bei einer Einschränkung des Typs wird der Compiler sicherstellen, dass die konkreten Typen die vorgeschriebene Schnittstelle haben und damit die Methoden existieren. Nehmen wir an, wir wollten ein typsicheres max() implementieren. Es soll den größeren der beiden Werte zurückgeben. Vergleiche lassen sich einfach tätigen, wenn die Objekte Comparable implementieren, denn compareTo() liefert einen Rückgabewert, der aussagt, welches Objekt nach der definierten Metrik kleiner, größer oder gleich ist.
    public static <T extends Comparable> T max( T m, T n )
    {
      return m.compareTo( n ) > 0 ? m : n;
    }
Die Nutzung ist einfach:
    System.out.println( Util.max( "Kino", "Lesen" ) );                    // Lesen
    System.out.println( Util.max( new Integer(12), new Integer(100) ) );  // 100
#### Einschränkung mit super Neben extends kann der Typ auch mit super eingeschränkt werden. Während extends eine Familie von abgeleiteten Untertypen spezifiziert, bestimmt super eine Familie von Typen, bei dem zu einem Typ T die Oberklassen von T, implementierte Schnittstellen von T inklusive der genannte Typ T selbst eingeschlossen sind.

Tabelle 9.1 Einige eingeschlossene Typen bei extends und super

T extends CharSequence | T super String
CharSequence | String
String | CharSequence
StringBuffer | Object
StringBuilder |
#### Weitere Obertypen mit & Soll der konkrete Typ zu mehreren Typen passen, lassen sich mit einem & weitere Obertypen hinzunehmen. Wichtig ist aber, dass nur eine Klassen-Vererbungsangabe stattfinden kann, also nur ein extends stehen darf, da Java keine Mehrfachvererbung auf Klassenebene unterstützt. Bei dem Rest muss es sich um implementierte Schnittstellen handeln. Nehmen wir eine Oberklasse O und die Schnittstellen I1 und I2 an. Dann sind die folgenden Deklarationen erlaubt: <T extends O> <T extends I1 & I2> <T extends O & I1> <T extends O & I1 & I2> Falsch wäre etwa <T extends O1 & T extends O2>. ### 9.1.6 Generics und Vererbung, Invarianz Im Zusammenhang mit Generics und Vererbung muss beachtet werden, dass die übliche Substitution nicht funktioniert. Wenn Player eine Unterklasse von GameObject ist, so ist Box<Player> keine Unterklasse von Box<GameObject>, genauso wie Box<Object> nicht die Oberklasse von Box<GameObject> ist beziehungsweise eine Box, die alle erdenklichen Typen ermöglicht. Der Compiler meckert bei diesem Versuch sofort:
    Box<Object> box;
    box = new Box<GameObject>();      // incompatible types
Die Erklärung ist schnell an einem Beispiel gezeigt. Da nun die Box in setValue() alles vom Typ Object aufnimmt – und ein String ist ein Object –, scheint folgender Argumenttyp zu funktionieren:
    box.setValue( "Invarianz" );
Doch da die Box tatsächlich mit Spielobjekten aufgebaut wurde, passt der String hier nicht hinein. Die Ableitungsbeziehung zwischen Typargumenten überträgt sich folglich nicht auf generische Klassen. Das wäre ein Fehler, und daher gibt es keine Kovarianz bei Generics; die Tatsache nennt sich Invarianz. Bei Methodenaufrufen ist das besonders lästig, doch werden wir im nächsten Abschnitt mit den Wildcards eine Lösung kennenlernen. Es wird damit
    void out( Box<GameObject> g )
nur eine Box mit GameObject aufnehmen können, aber zum Beispiel keine Box<Player>. ### 9.1.7 Wildcards Ein bewusstes »Vergessen« der Typinformationen lässt sich durch die Wildcard ? erreichen. Es erlaubt aber auch, verschiedene Unterklassen zusammenzuführen. Wir haben schon oben gesehen, dass etwa Folgendes nicht funktioniert: Listing 9.6 com/tutego/insel/generics/GenericBoxExample4.java, Ausschnitt
    Box<Number>  numberBox;
    Box<Integer> bI = new Box<Integer>();
    Box<Double>  bD = new Box<Double>();
    numberBox = bI;                           // Compilerfehler Type mismatch
Über Wildcards ist es jedoch möglich, den Typ von numberBox frei zu lassen, was jetzt aber nicht so gemeint ist, dass wir die Box gänzlich ohne generische Syntax deklarieren, sondern als:
    Box<?> b;
Das Fragezeichen in der Angabe steht für alle Boxen und für alle Untertypen T im Fall von Box<T>. Es ist wichtig zu verstehen, dass ? nicht für Object steht, sondern für einen unbekannten Typ! Da die Wildcards auch mit Typeinschränkung arbeiten, können wir auf diese Weise eine Box von Number-Objekten aufbauen:
    Box<? extends Number> numberBox;
    Box<Integer> intBox    = new Box<Integer>();
    Box<Double>  doubleBox = new Box<Double>();
    Box<String>  stringBox = new Box<String>();
Die Schreibweise <? extends Klasse> nennt sich upper-bound wildcard. (Eine Einschränkung der Art <? super Klasse> heißt lower-bound wildcard.) So funktioniert die Zuweisung:
    numberBox = intBox;           // oder numberBox = doubleBox;
Aber nicht so:
    numberBox = stringBox;        // Type mismatch
Die Nutzung der numberBox ist jedoch insofern eingeschränkt, als das setValue() nur über die konkrete Box, also etwa intBox, funktioniert, aber nicht über die allgemeine numberBox. Der Zugriff ist unproblematisch.
    numberBox.setValue( 1 );      // Compilerfehler
    intBox.setValue( 1 );
    Number number = numberBox.getValue();
    System.out.println( number ); // 1
Weitere Anwendungen der upper-bound wildcard und lower-bound wildcard beschreibt das Kapitel 12 über Datenstrukturen. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Zum Katalog
Java ist auch eine Insel Jetzt bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Tipp
| Coding for Fun
Buchempfehlungen
| Objektorientierte Programmierung
| Einstieg in Eclipse 3.4
| Java 6 lernen mit Eclipse
| NetBeans Platform 6
| Java und XML
| Visual C# 2008
| IT-Handbuch für Fachinformatiker
| C++ von A bis Z
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 2009
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.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de