6.10 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.10.1 Deklarieren von Schnittstellen

Eine Schnittstelle enthält keine Implementierungen, sondern deklariert nur den Kopf einer Methode – also Modifizierer, den Rückgabetyp und 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.80 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 an Stelle 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 Funktionen ausprogrammiert werden und keine Objektvariablen deklariert werden dürfen, sind static final-Variablen (benannte Konstanten) in einer Schnittstelle erlaubt, statische Funktionen jedoch nicht.

6.10.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.81 com/tutego/insel/game/vk/Chocolate.java, Chocolate

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

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

Listing 6.82 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 abstrakte Funktionen und muss selbst wieder als abstrakt gekennzeichnet werden.

6.10.3 Markierungsschnittstellen

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

package java.io; 
interface Serializable 
{ 
}

6.10.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 Funktion der 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 Funktion 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 schreiben, die den Preis einer Sammlung kaufbarer Objekte berechnet. Sie soll wie folgt aufgerufen werden:

Listing 6.84 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.85 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 Funktion 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.10.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.

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.86 com/tutego/insel/game/vl/GameObject.java, GameObject

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

GameObject soll die Markierungsschnittstelle Serializable implementieren, sodass dann alle Unterklassen von GameObject ebenfalls vom Typ Serializable sind. Die Markierungsschnittstelle schreibt nichts vor, daher gibt es keine spezielle überschriebene Funktion.

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

interface Buyable 
{ 
  double price(); 
}

Listing 6.88 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:

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

• Ü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.

• Die Variable m4 ist vom Typ Buyable, sodass es price() gibt, jedoch kein compareTo().

• 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 Funktion aufrufen, denn Serializable ist eine Markierungsschnittstelle ohne Operationen.

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

Listing 6.89 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 Methode 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.10.6 Keine Kollisionsgefahr bei Mehrfachvererbung

Das Dilemma bei der Mehrfachvererbung von Klassen wäre, dass zwei Oberklassen die gleiche Funktion 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 Funktion 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.90 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.10.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 implementiert, 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.10.8 Vererbte Konstanten bei Schnittstellen

Schnittstellen können Variablen besitzen, die jedoch, wie wir gesehen haben, 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.91 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.10.9 Schnittstellenmethoden, die nicht implementiert werden müssen

Bis auf eine Ausnahme muss eine Klasse, zu der Exemplare erzeugt werden sollen, alle Methoden der Schnittstellen implementieren. Eine Ausnahme ergibt sich wieder aus der Tatsache, dass jede Schnittstelle die Methoden von Object annimmt. Sehen wir uns den Programmcode der Schnittstelle Comparator an, die im Paket java.util deklariert ist:

package java.util; 
 
public interface Comparator<T> 
{ 
  int compare( T o1, T o2 ); 
  boolean equals( Object obj ); 
}

Wir entdecken, dass dort die equals()-Methode vorgeschrieben wird. Der erste Gedanke ist, nun eine Klasse zu schreiben, die compare() und equals() implementieren muss. Dies ist hier allerdings nicht nötig, da equals()schon eine Methode ist, die jedes Objekt besitzt. Daraus ergibt sich, dass nicht alle Methoden ausprogrammiert werden müssen. (Eventuell überschreiben wir equals(), wenn uns die Semantik von equals() in Object nicht gefällt.) Außerdem lässt sich eine Schnittstelle angeben, die die Methoden von Object auflistet. Auch dann müsste keine Methode implementiert werden. Bleibt die Frage, warum denn Comparator eine equals()-Methode vorschreibt, wenn diese doch nicht implementiert zu werden braucht. Um uns zu verwirren? Nein. Der Sinn besteht einfach darin, die Funktionsweise in der Dokumentation genau anzugeben. Eine Java-Dokumentation kann nur generiert werden, wenn auch eine Funktion im Quellcode vorhanden ist. Die Entwickler wollten bei equals() in der Schnittstelle Comparator noch einmal bewusst auf die Funktion hinweisen, dass equals() zwei Comparator-Objekte daraufhin vergleicht, ob beide die gleiche Sortierfolge verwenden, und nicht (wie wir annehmen könnten) zwei Objekte auf Gleichheit testet.

6.10.10 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 der, 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 einer 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