11.3    Die Typen über Bounds einschränken 

Bei generischen Angaben können die Typen weiter eingeschränkt werden. Das ist nützlich, da ein beliebiger Typ oft zu allgemein ist. Unsere Deklaration von random(…) sah keine Einschränkungen für die Typen vor:

public static <T> T random( T m, T n ) {

  return Math.random() > 0.5 ? m : n;

}

So ist Folgendes möglich:

Object o1 = new Object();

Object o2 = new Point();

System.out.println( random( o1, o2 ) );

Da der Typ beliebig ist, können Objekte übergeben werden, die vielleicht wenig Sinn ergeben, insbesondere in ihrer Kombination.

 

11.3.1    Einfache Einschränkungen mit extends 

Bei der Deklaration eines generischen Typs kann vorgeschrieben werden, dass der spätere parametrisierte Typ eine bestimmte Klasse erweitert oder eine konkrete Schnittstelle implementiert. Soll unsere statische random(…)-Methode zum Beispiel nur Objekte vom Typ CharSequence (also Zeichenfolgen wie String und StringBuffer/StringBuilder) akzeptieren, so schreiben wir das in die Deklaration mit hinein:

Listing 11.10    src/main/java/com/tutego/insel/generic/BondageBounds.java, BondageBounds

public class BondageBounds {



  public static <T extends CharSequence> T random( T m, T n ) {

    return Math.random() > 0.5 ? m : n;

  }



  public static void main( String[] args ) {

    String random1 = random( "Shinju", "Karada" );

    System.out.println( random1 );



    CharSequence random2 = random( "Ushiro", new StringBuilder("Takatekote") );

    System.out.println( random2 );

  }

}

Einen Aufruf mit zwei Strings lässt der Compiler korrekterweise durch, genauso wie mit String und StringBuilder, wobei der Rückgabetyp dann nur noch CharSequence ist.

Ein Fehler ist leicht zu provozieren. Dazu muss der Methode random(…) nur etwa ein Point übergeben werden – Point ist nicht vom Typ CharSequence. So führt

System.out.println( random( "", new Point() ) ); //  Compilerfehler

                                                 // "Bound mismatch"

zu der Fehlermeldung: »Bound mismatch: The generic method random(T, T) of type BondageBounds is not applicable for the arguments (String, Point). The inferred type Serializable is not a valid substitute for the bounded parameter <T extends CharSequence>«.

Der Compiler führt eine Typ-Inferenz durch. Das heißt, er schaut sich an, welche gemeinsamen Typen die Argumente "" und Point haben, und kommt auf Serializable. Der Typ hilft jedoch nicht weiter, denn wir wollten bloß CharSequences einsetzen können.

Typeinschränkung für gemeinsame Methoden

Eine Typeinschränkung wie <T extends CharSequence> ist interessant, da wir so wissen, dass ein konkretes Typargument (etwa String oder StringBuffer) mindestens die Methoden der Schnittstelle CharSequence hat. Das ist logisch, denn bei einer Einschränkung des Typs wird der Compiler sicherstellen, dass die konkreten Typen die vorgeschriebene Schnittstelle implementieren (oder die Klasse erweitern), und damit stellt er sicher, dass 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.

Listing 11.11    src/main/java/com/tutego/insel/generic/BondageBounds.java, max()

public static <T extends Comparable<T>> T max( T m, T n ) {

  return m.compareTo( n ) > 0 ? m : n;

}

Die Nutzung ist einfach:

System.out.println( max( "Kino", "Lesen" ) );              // Lesen

System.out.println( max( 12, 100 ) );                      // 100

Betrachten wir einen Fehlerfall. Intuitiv ist anzunehmen, dass alles, was vom Typ Comparable ist, ein gültiger Argumenttyp für max(…) ist. Das ist aber nicht ganz präzise, denn wir schreiben <T extends Comparable<T>> T max(T m, T n), was bedeutet, dass der gemeinsame Typ für m und n laut Typ-Inferenz Comparable sein muss, nicht nur jeder einzelne. Was das bedeutet, zeigt die folgende Anweisung, die der Compiler mit einem Fehler ablehnt:

System.out.println( max( 12L, 100F ) );  //  Compilerfehler "incompatible mismatch"

Nach dem Boxing leitet der Compiler aus dem Long 12 und dem Float 100 den gemeinsamen Typ Number ab. (Zur Erinnerung: Der Compiler geht in der Typhierarchie so lange nach oben, bis ein gemeinsamer Typ gefunden wurde, der für T eingesetzt werden kann; das ist Number.) Aber Number ist nicht vom Typ Comparable, und so folgt eine Fehlermeldung:

error: method max in class ... cannot be applied to given types;

    System.out.println( max( 12L, 100F ) );

                        ^

  required: V,V

  found: long,float

  reason: inference variable V has incompatible bounds

    equality constraints: Long,Float

    lower bounds: Float,Long

  where V is a type-variable:

    V extends Comparable<V> declared in method <V>max(V,V)

static <T extends Comparable/*Hier fehlt was*/> T max( T m, T n ) { … }

 

11.3.2    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. Die allgemeine Notation (für eine Klasse C und Schnittstellen I1 bis In) ist: T extends C & I1 & I2 & … & In.

Nehmen wir eine fiktive Oberklasse Endeavour und die Schnittstellen Serializable und Comparable an.[ 215 ](Comparable bekommt selbst einen Typparameter, was das Beispiel aus Gründen der Übersichtlichkeit auslässt. ) Dann sind die folgenden Deklarationen prinzipiell erlaubt:

• <T extends Endeavour>

• <T extends Serializable & Comparable>

• <T extends Endeavour & Serializable>

• <T extends Endeavour & Comparable & Serializable>

Syntaktisch falsch wäre etwa <T extends Endeavour & T extends Comparable>, da das Schlüsselwort extends nur einmal vorkommen darf.