6.13 Schnittstellen

Da Java nur Einfachvererbung kennt, ist es schwierig, Klassen mehrere Typen zu geben. Das kann immer nur in einer Reihe geschehen, also etwa GameObject erbt von Object, Building erbt von GameObject, Castle erbt von Building usw. Es wird schwierig, an einer Stelle zu sagen, dass ein Building ein GameObject ist, aber zum Beispiel noch zusätzlich einen Typ Preis haben soll, was nur nicht gleich alle Spielobjekte haben sollen. Denn soll eine Klasse auf einer Ebene von mehreren Typen erben, geht das durch die Einfachvererbung nicht. Da es aber möglich sein soll, dass in der objektorientierten Modellierung eine Klasse mehrere Typen in einem Schritt besitzt, gibt es das Konzept der Schnittstelle (engl. interface). Eine Klasse kann dann neben der Oberklasse eine beliebige Anzahl Schnittstellen implementieren und auf diese Weise weitere Typen sammeln.

6.13.1 Deklarieren von Schnittstellen

Eine Schnittstelle enthält keine Implementierungen, sondern deklariert nur den Kopf einer Methode – also Modifizierer, den Rückgabetyp und die Signatur – ohne Rumpf.

Sollen in einem Spiel gewisse Dinge käuflich sein, haben sie einen Preis. Eine Schnittstelle Buyable soll allen Klassen die Methode price() vorschreiben.

Listing 6.85 com/tutego/insel/game/vk/Buyable.java, Buyable

interface Buyable 
{ 
  double price(); 
}

Die Deklaration einer Schnittstelle erinnert an eine abstrakte Klasse mit abstrakten Methoden, nur steht anstelle von class das Schlüsselwort interface. Da alle Methoden in Schnittstellen automatisch abstrakt und öffentlich sind, akzeptiert der Compiler das redundante abstract und public, doch die Modifizierer sollten nicht geschrieben werden. Die von den Schnittstellen deklarierten Operationen sind – wie auch bei abstrakten Methoden – mit einem Semikolon abgeschlossen und haben niemals eine Implementierung.

Eine Schnittstelle darf keinen Konstruktor deklarieren. Das ist auch klar, da Exemplare von Schnittstellen nicht erzeugt werden können, sondern nur von den konkreten implementierenden Klassen.

Obwohl in einer Schnittstelle keine Methoden ausprogrammiert werden und keine Objektvariablen deklariert werden dürfen, sind static final-Variablen (benannte Konstanten) in einer Schnittstelle erlaubt, statische Funktionen jedoch nicht.

Existiert eine Klasse, in der Methoden in einer neuen Schnittstelle deklariert werden sollen, lässt sich Refactor • Extract Interface... einsetzen. Es folgt ein Dialog, der uns Methoden auswählen lässt, die später in der neuen Schnittstelle deklariert werden. Eclipse legt die Schnittstelle automatisch an und lässt die Klasse die Schnittstelle implementieren. Dort, wo es möglich ist, erlaubt Eclipse, dass die konkrete Klasse durch die Schnittstelle ersetzt wird.

6.13.2 Implementieren von Schnittstellen

Möchte eine Klasse eine Schnittstelle verwenden, so folgt hinter dem Klassennamen das Schlüsselwort implements und dann der Name der Schnittstelle. Die Ausdrucksweise ist dann: »Klassen werden vererbt und Schnittstellen implementiert.«

Für unsere Spielwelt sollen die Klassen Chocolate und Magazine die Schnittstelle Buyable implementieren.

Listing 6.86 com/tutego/insel/game/vk/Chocolate.java, Chocolate

public class Chocolate implements Buyable 
{ 
  @Override public double price() 
  { 
    return 0.69; 
  } 
}

Die Annotation @Override zeigt wieder eine überschriebene Methode (hier implementierte Methode einer Schnittstelle) an. (Unter Java 5 führte @Override an implementierten Methoden einer Schnittstelle zu einem Compilerfehler.)

Während Chocolate nur die Schnittstelle Buyable implementiert, soll Magazine zusätzlich ein GameObject sein:

Listing 6.87 com/tutego/insel/game/vk/Magazine.java, Magazine

public class Magazine extends GameObject implements Buyable 
{ 
  double price; 
 
  @Override public double price() 
  { 
    return price; 
  } 
}

Es ist also kein Problem – und bei uns so gewünscht –, wenn eine Klasse eine andere Klasse erweitert und zusätzlich Operationen aus Schnittstellen implementiert.

Implementiert eine Klasse nicht alle Operationen aus den Schnittstellen, so erbt sie damit ab-strakte Methoden und muss selbst wieder als abstrakt gekennzeichnet werden.

Eclipse zeigt bei der Tastenkombination + eine Typhierarchie an, also Oberklassen stehen oben und Unterklassen unten. Wird in dieser Ansicht erneut + gedrückt, wird die Ansicht umgedreht, dann stehen die Obertypen unten, was den Vorteil hat, dass auch die implementierte Schnittstelle unter den Obertypen ist.

6.13.3 Markierungsschnittstellen

Auch Schnittstellen ohne Methoden sind möglich. Diese leeren Schnittstellen werden Markierungsschnittstellen (engl. marker interfaces) genannt. Sie sind nützlich, da mit instanceof leicht überprüft werden kann, ob sie einen gewollten Typ einnehmen.

Die Sun-Bibliothek bringt einige Markierungsschnittstellen schon mit, etwa: java.util.RandomAccess, java.rmi.Remote, java.lang.Cloneable, java.util.EventListener und java. io.Serializable [Implementiert eine Klasse Serializable, so lassen sich die Zustände eines Objekts in einen Datenstrom schreiben. (Mehr dazu in Kapitel 14, »Dateien und Datenströme«.)] .

Listing 6.88 java/lang/Serializable.java

package java.io; 
interface Serializable 
{ 
}

6.13.4 Ein Polymorphie-Beispiel mit Schnittstellen

Obwohl Schnittstellen auf den ersten Blick nichts »bringen« – Programmierer wollen gerne etwas vererbt bekommen, damit sie Implementierungsarbeit sparen können –, sind sie eine enorm wichtige Erfindung, da sich über Schnittstellen ganz unterschiedliche Sichten auf ein Objekt beschreiben lassen. Jede Schnittstelle ermöglicht eine neue Sicht auf das Objekt, eine Art Rolle. Implementiert eine Klasse diverse Schnittstellen, können ihre Exemplare in verschiedenen Rollen auftreten. Hier wird erneut das Substitutionsprinzip wichtig, bei dem ein mächtigeres Objekt verwendet wird, obwohl je nach Kontext nur die Methode der Schnittstellen erwartet wird.

Mit Magazine und Chocolate haben wir zwei Klassen, die Buyable implementieren. Damit existieren zwei Klassen, die einen gemeinsamen Typ und beide eine gemeinsame Methode price() besitzen.

Buyable b1 = new Magazine(); 
Buyable b2 = new Chocolate(); 
System.out.println( b1.price() ); 
System.out.println( b2.price() );

Für Buyable wollen wir eine Funktion calculateSum() schreiben, die den Preis einer Sammlung kaufbarer Objekte berechnet. Sie soll wie folgt aufgerufen werden:

Listing 6.89 com/tutego/insel/game/vk/Playground.java, main()

Magazine madMag = new Magazine(); 
madMag.price = 2.50; 
Buyable schoki = new Chocolate(); 
Magazine maxim = new Magazine(); 
maxim.price = 3.00; 
System.out.printf( "%.2f", PriceUtils.calculateSum( madMag, maxim, schoki ) );   
// 6,19

Damit calculateSum() eine beliebige Anzahl Argumente, aber mindestens eins, annehmen kann, realisieren wir die Funktion mit einem Vararg:

Listing 6.90 com/tutego/insel/game/vk/PriceUtils.java, calculateSum()

static double calculateSum( Buyable price1, Buyable... prices ) 
{ 
  double result = price1.price(); 
  for ( Buyable price : prices ) 
    result += price.price(); 
 
  return result; 
}

Die Methode nimmt käufliche Dinge an, wobei es ihr völlig egal ist, um welche es sich dabei handelt. Was zählt, ist die Tatsache, dass die Elemente die Schnittstelle Buyable implementieren.

Die Polymorphie tritt schon in der ersten Anweisung price1.price() auf. Auch später rufen wir auf jedem Objekt, das Buyable implementiert, die Methode price() auf. Indem wir die unterschiedlichen Werte summieren, bekommen wir den Gesamtpreis der Elemente aus der Parameterliste.

Im Zusammenhang mit Schnittstellen bleibt zusammenfassend zu sagen, dass hier dynamisches Binden pur auftaucht.

6.13.5 Die Mehrfachvererbung bei Schnittstellen

Bei Klassen gibt es die Einschränkung, dass nur von einer direkten Oberklasse abgeleitet werden darf – egal, ob sie abstrakt ist oder nicht. Wird hingegen eine Schnittstelle implementiert, dann werden nicht mehr aus verschiedenen Quellen unterschiedliche Implementierungen für dieselbe Methode angeboten, was zu Problemen führen kann. Ohne Schwierigkeiten kann eine Klasse mehrere Schnittstellen implementieren. Dies wird gelegentlich als »Mehrfachvererbung in Java« bezeichnet. Auf diese Weise besitzt die Klasse ganz unterschiedliche Typen, da sie nun instanceof der Oberklasse – beziehungsweise der indirekten Oberklassen – sowie der Schnittstellen ist.

Beginnen wir mit einem Beispiel. GameObject soll die Markierungsschnittstelle Serializable implementieren, sodass dann alle Unterklassen von GameObject ebenfalls vom Typ Seriali-zable sind. Die Markierungsschnittstelle schreibt nichts vor, daher gibt es keine spezielle überschriebene Methode.

Listing 6.91 com/tutego/insel/game/vl/GameObject.java, GameObject

public abstract class GameObject implements Serializable 
{ 
  protected String name; 
 
  protected GameObject( String name ) 
  { 
    this.name = name; 
  } 
}

Damit gibt es schon verschiedene Ist-eine-Art-von-Beziehungen: GameObject ist ein java.lang.Object, GameObject ist ein GameObject, GameObject ist Serializable.

Ein Magazine soll zunächst ein GameObject sein. Dann soll es nicht nur die Schnittstelle Buyable und damit die Methode price()implementieren, sondern sich auch mit anderen Magazinen vergleichen lassen. Dazu gibt es schon eine passende Schnittstelle in der Java-Bibliothek: java.lang.Comparable. Die Schnittstelle Comparable fordert, dass unser Magazin die Methode int compareTo(Magazine) implementiert. Der Rückgabewert der Methode zeigt an, wie das eigene Magazin zum anderen aufgestellt ist. Wir wollen definieren, dass das günstigere Magazin vor einem teureren steht.

Listing 6.92 com/tutego/insel/game/vl/Buyable.java, Buyable

interface Buyable 
{ 
  double price(); 
}

Listing 6.93 com/tutego/insel/game/vl/Magazine.java, Magazine

public class Magazine extends GameObject implements Buyable, Comparable<Magazine> 
{ 
  private double price; 
 
  public Magazine( String name, double price ) 
  { 
    super( name ); 
    this.price = price; 
  } 
 
  @Override public double price() 
  { 
    return price; 
  } 
 
  @Override public int compareTo( Magazine that ) 
  { 
    return this.price() < that.price() ? –1 : (this.price() > that.price() ? +1 : 0); 
  } 
  @Override public String toString() 
  { 
 
    return name + " " + price; 
  } 
}

Die Implementierung nutzt Generics mit Comparable<Buyable>, was wir genauer erst später lernen, aber an der Stelle schon einmal nutzen wollen. Der Hintergrund ist, dass Comparable dann genau weiß, mit welchem anderen Typ der Vergleich stattfinden soll.

Durch diese »Mehrfachvererbung« bekommt Magazine mehrere Typen, sodass sich je nach Sichtweise schreiben lässt:

Magazine             m1  = new Magazine( "Mad Magazine", 2.50 ); 
GameObject           m2  = new Magazine( "Mad Magazine", 2.50 ); 
Object               m3  = new Magazine( "Mad Magazine", 2.50 ); 
Buyable              m4  = new Magazine( "Mad Magazine", 2.50 ); 
Comparable<Magazine> m5  = new Magazine( "Mad Magazine", 2.50 ); 
Serializable         m6  = new Magazine( "Mad Magazine", 2.50 );

Die Konsequenz davon ist:

• Im Fall m1 sind alle Methoden der Schnittstellen verfügbar, also price() und compareTo() sowie das Attribut name.

• Über m2 ist keine Schnittstellenmethode verfügbar, und nur die geschützte Variable name ist vorhanden.

• Mit m3 sind alle Bezüge zu Spielobjekten verloren. Aber ein Magazine als Object ist gültiger Argumenttyp für System.out.println(Object).

• Die Variable m4 ist vom Typ Buyable, sodass es price() gibt, jedoch kein compareTo(). Das Objekt könnte daher in PriceUtils.calculateSum() eingesetzt werden.

• Mit m5 gibt es ein compareTo(), aber keinen Preis.

• Da Magazine die Klasse GameObject erweitert und darüber auch vom Typ Serialize ist, lässt sich keine besondere Methode aufrufen – Serializable ist eine Markierungsschnittstelle ohne Operationen. Damit könnte das Objekt allerdings von speziellen Klassen der Java-Bibliothek serialisiert und so persistent gemacht werden.

Ein kleines Beispiel zeigt abschließend die Anwendung der Methoden compareTo() der Schnittstelle Comparable und price() der Schnittstelle Buyable.

Listing 6.94 com/tutego/insel/game/vl/Playground.java, main()

Magazine spiegel = new Magazine( "Spiegel", 3.50 ); 
Magazine madMag  = new Magazine( "Mad Magazine", 2.50 ); 
Magazine maxim   = new Magazine( "Maxim", 3.00 ); 
Magazine neon    = new Magazine( "Neon", 3.00 ); 
Magazine ct      = new Magazine( "c't", 3.30 );

Da wir einem Magazin so viele Sichten gegeben haben, können wir es natürlich mit unserer früheren Funktion calculateSum() aufrufen, da jedes Magazine ja Buyable ist:

System.out.println( PriceUtils.calculateSum( spiegel, madMag, ct ) ); // 9.3

Und die Magazine können wir vergleichen:

System.out.println( spiegel.compareTo( ct ) );  // 1 
System.out.println( ct.compareTo( spiegel ) );  // –1 
System.out.println( maxim.compareTo( neon ) );  // 0

So wie es der Funktion calculateSum() egal ist, was für Buyable-Objekte konkret übergeben werden, gibt es auch für Comparable einen sehr nützlichen Anwendungsfall: Sortieren. Einem Sortierverfahren ist es egal, was für Objekte genau es sortiert, solange die Objekte sagen, ob sie vor oder hinter einem anderen Objekt liegen.

Magazine[] mags = new Magazine[] { spiegel, madMag, maxim, neon, ct }; 
Arrays.sort( mags ); 
System.out.println( Arrays.toString( mags ) ); 
// [Mad Magazine 2.5, Maxim 3.0, Neon 3.0, c't 3.3, Spiegel 3.5]

Die Funktion Arrays.sort() erwartet ein Feld, dessen Elemente Comparable sind. Der Sortieralgorithmus macht Vergleiche über compareTo(), muss aber sonst über die Objekte nichts wissen. Unsere Magazine mit den unterschiedlichen Typen können also sehr flexibel in unterschiedlichen Kontexten eingesetzt werden. Es muss somit für das Sortieren keine Spezialsortierfunktion geschrieben werden, die nur Magazine sortieren kann, oder eine Funktion zur Berechnung einer Summe, die nur auf Magazinen arbeitet. Wir modellieren die unterschiedlichen Anwendungsszenarien mit jeweils unterschiedlichen Schnittstellen, die Unterschiedliches von dem Objekt erwarten.

6.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung

Das Dilemma bei der Mehrfachvererbung von Klassen wäre, dass zwei Oberklassen die gleiche Methode mit zwei unterschiedlichen Implementierungen vererben könnten. Die Unterklasse wüsste dann nicht, welche Logik sie erbt. Bei den Schnittstellen gibt es das Problem nicht, denn auch wenn zwei implementierende Schnittstellen die gleiche Methode vorschreiben würden, gäbe es keine zwei verschiedenen Implementierungen von Anwendungslogik. Die implementierende Klasse bekommt sozusagen zweimal die Aufforderung, die Operation zu implementieren. So wie bei folgendem Beispiel: Ein Politiker muss verschiedene Dinge vereinen; er muss sympathisch, aber auch durchsetzungsfähig handeln können.

Listing 6.95 Politician.java

interface Likeable 
{ 
  void act(); 
} 
 
interface Assertive 
{ 
  void act(); 
} 
 
public class Politician implements Likeable, Assertive 
{ 
  public void act() 
  { 
    // Implementation 
  } 
}

Zwei Schnittstellen schreiben die gleiche Operation vor. Eine Klasse implementiert diese beiden Schnittstellen und muss beiden Vorgaben gerecht werden.

6.13.7 Erweitern von Interfaces – Subinterfaces

Ein Subinterface ist die Erweiterung eines anderen Interfaces. Diese Erweiterung erfolgt – wie bei der Vererbung – durch das Schlüsselwort extends.

interface Disgusting 
{ 
  double disgustingValue(); 
} 
 
interface Stinky extends Disgusting 
{ 
  double olf(); 
}

Die Schnittstelle modelliert Stinkiges, was besonders abstoßend ist. Zusätzlich soll die Stinkquelle die Stärke der Stinkigkeit in der Einheit Olf angeben. Eine Klasse, die nun Stinky im-plementiert, muss die Methoden aus beiden Schnittstellen implementieren, demnach die Methode disgustingValue() aus Disgusting sowie die Operation olf(), die in Stinky selbst angegeben wurde. Ohne die Implementierung beider Methoden wird eine implementierende Klasse abstrakt sein müssen.

6.13.8 Vererbte Konstanten bei Schnittstellen

Schnittstellen können Attribute besitzen, die jedoch immer automatisch statisch und final, also Konstanten sind. Diese Konstanten können einer anderen Schnittstelle vererbt werden. Dabei gibt es einige kleine Einschränkungen.

Wir wollen an einem Beispiel sehen, wie sich die Vererbung auswirkt, wenn gleiche Bezeichner in den Unterschnittstellen erneut verwendet werden.

Listing 6.96 Colors.java

interface BaseColors 
{ 
  int RED     = 1; 
  int GREEN   = 2; 
  int BLUE    = 3; 
} 
 
interface CarColors extends BaseColors 
{ 
  int BLACK   = 10; 
  int PURPLE  = 11; 
} 
 
interface CoveringColors extends BaseColors 
{ 
  int PURPLE  = 11; 
  int BLACK   = 20; 
  int WHITE   = 21; 
} 
 
interface AllColors extends CarColors, CoveringColors 
{ 
  int WHITE  = 30; 
} 
public class Colors 
{ 
  @SuppressWarnings("all") 
  public static void main( String[] args ) 
  { 
    System.out.println( CarColors.RED );        // 1 
    System.out.println( AllColors.RED );        // 1 
    System.out.println( CarColors.BLACK );      // 10 
    System.out.println( CoveringColors.BLACK ); // 20 
 
//    System.out.println( AllColors.BLACK );   // The field AllColors.BLACK is ambiguous 
//    System.out.println( AllColors.PURPLE );  // The field AllColors.PURPLE is ambiguous 
  } 
}

Die erste wichtige Tatsache ist, dass Schnittstellen ohne Fehler übersetzt werden können. Doch das Programm zeigt weitere Eigenschaften:

6.13.9 Abstrakte Klassen und Schnittstellen im Vergleich

Eine abstrakte Klasse und eine Schnittstelle sind sich sehr ähnlich: Beide schreiben den Unterklassen beziehungsweise den implementierten Klassen Operationen vor, die sie implementieren müssen. Ein wichtiger Unterschied ist jedoch, dass beliebig viele Schnittstellen implementiert werden können, doch nur eine Klasse – sei sie abstrakt oder nicht – erweitert werden kann. Des Weiteren bieten sich abstrakte Klassen meist im Refactoring oder in der Design-Phase an, wenn Gemeinsamkeiten in eine Oberklasse ausgelagert werden sollen. Abstrakte Klassen können zusätzlichen Programmcode enthalten, was Schnittstellen nicht können. Auch nachträgliche Änderungen an Schnittstellen sind nicht einfach: Einer abstrakten Klasse kann eine konkrete Methode mitgegeben werden, was zu keiner Quellcodeanpassung für Unterklassen führt.

Ein Beispiel: Ist eine Schnittstelle oder eine abstrakte Klasse besser, um folgende Operation zu deklarieren?

abstract class Timer                          interface Timer 
{                                             { 
  abstract long getTimeInMillis();              long getTimeInMillis(); 
}                                             }

Eine abstrakte Klasse hätte den Vorteil, dass später einfacher eine Methode wie getTimeInSeconds() eingeführt werden kann, die konkret sein darf. Würde diese angenehme Hilfsoperation in einer Schnittstelle vorgeschrieben, so müssten alle Unterklassen diese Implementierung immer neu einführen, wobei sie doch schon in der abstrakten Oberklasse einfach programmiert werden könnte:

abstract class Timer 
{ 
  abstract long getTimeInMillis(); 
 
  long getTimeInSeconds() 
  { 
    return getTimeInMillis() / 1000; 
  } 
}

Ihr Kommentar