6.11 Schnittstellen 

Eine Schnittstelle¹  (interface) enthält keine Implementierungen, sondern nur Namen und Signaturen der enthaltenen Methoden. Anders gesagt, sie sind vollständig abstrakte Klassen.

package vd;
  interface   Unterhaltend
{
  int unterhaltungswert();
}

Die Definiten einer Schnittstelle erinnert an eine abstrakte Klasse mit abstrakten Methoden, nur anstatt class steht das Schlüsselwort interface, und bei den abstrakten Klassen muss der Modifizierer abstract nicht geschrieben werden; alle Methoden in Schnittstellen sind automatisch abstrakt und auch öffentlich. (Der Compiler akzeptiert natürlich redundante Angaben von abstract und public. Sie sollten aber nicht geschrieben werden.)

Eine Schnittstelle darf keinen Konstruktor definieren. Das ist auch klar, da Exemplare von Schnittstellen nicht erzeugt werden können.

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 sind jedoch nicht erlaubt.

Hier klicken, um das Bild zu Vergrößern

Existiert eine Klasse, in der Methoden in einer neuen Schnittstelle definiert werden sollen, lässt sich Refactor, Extract Interface… einsetzen. Es folgt ein Dialog, der uns Methoden auswählen lässt, die später in einer neuen Schnittstelle definiert 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.

Implementieren von Schnittstellen

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

Die Klasse Kirche soll die Schnittstelle Unterhaltend implementieren und verpflichtet sich damit, alle beschriebenen Methoden zu implementieren. Unsere Klasse Kirche soll ein Gebaude sein und Unterhaltend sein. Damit wird sie eine Methode unterhaltungswert() besitzen.

Listing 6.50   vd/Kirche.java

package vd;

class Kirche extends Gebaeude   implements Unterhaltend  
{
  int anzahlBeichtstühle;

  int verfügbarerMesswein;

  /**
   * Liefert den Unterhaltungswert der Kirche.
   *
   * @return  Unterhaltungswert.
   */
    public int unterhaltungswert()  
    {  
      return anzahlBeichtstühle * verfügbarerMesswein * verfügbarerMesswein;  
    }  
}

Hier klicken, um das Bild zu Vergrößern

Abbildung 6.9   Kirche und Disko sind Gebäude und implementieren Unterhaltend

Implementiert eine Schnittstelle nicht alle Funktionen aus den Schnittstellen, so erbt sie damit eine abstrakte Funktion und muss selbst wieder als abstrakt gekennzeichnet werden.

Hier klicken, um das Bild zu Vergrößern

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

Hier klicken, um das Bild zu Vergrößern

Hier klicken, um das Bild zu Vergrößern

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.

interface Serializable
{
}

Was bringen 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. Denn über Schnittstellen lässt sich eine Sicht auf ein Objekt beschreiben. Jede Schnittstelle definiert solch eine Sicht, eine Art Rolle. Implementiert eine Klasse diverse Schnittstellen, so können ihre Exemplare in verschiedenen Rollen auftreten. Hier wird erneut das Substitutionsprinzip wichtig, bei dem ein mächtigeres Objekt verwendet wird, auch wenn weniger erwartet wird.

6.11.1 Ein Polymorphie-Beispiel mit Schnittstellen 

An dieser Stelle sei noch einmal an die Möglichkeit erinnert, Funktionen auf Objekte auszuführen, die eine gemeinsame Basis haben. Wir haben Disko und Kirche als zwei Klassen, die Unterhaltend implementieren und somit über die Funktion unterhaltungswert() verfügen. Diese Unterhaltungs-Klassen wollen wir in eine Container-Klasse aufnehmen, dem Unterhaltungsprogramm. Die Klasse soll neue Unterhaltende »Dinge« aufnehmen können. Dabei ist es der Klasse ziemlich egal, ob die Elemente Diskotheken, Kirchen oder Unterwäsche sind – Hauptsache die Elemente implementieren die Schnittstelle Unterhaltend. Die interessante Funktion ist daher:

void fügeHinzu( Unterhaltend u )

Intern sollen die Unterhaltend-Objekte in einem Feld ebenfalls vom Typ Unterhaltend gespeichert werden.

Hier klicken, um das Bild zu Vergrößern

Listing 6.51   vc/Unterhaltungsprogramm.java

package vd;

public class Unterhaltungsprogramm
{
  /**
   * Feld für die Unterhaltungs-Objekte.
   */
  private Unterhaltend programm[] = new Unterhaltend[ 10 ];

  /**
   * Aktuelle Anzahl von Unterhaltungs-Objekten.
   */
  private int pos;

  /**
   * Fügt ein neues Unterhaltungs-Objekt in das Unterhaltungsprogramm ein.
   *
   * @param u  Hinzuzufügendes Unterhaltungs-Objekt.
   */
  public void fügeHinzu( Unterhaltend u )
  {
    if ( pos < 10 )
      programm[ pos++ ] = u;
    else
      System.out.println( "Programm voll!" );
  }

  /**
   * Liefert den Gesamtunterhaltungswert aller Unterhaltungs-Objekte.
   */
  public double unterhaltungswert()
  {
    int uw = 0;

    for ( int i = 0; i < pos; i++ )
      uw +=   programm[ i ].unterhaltungswert();  


    return uw;
  }
}

Die Polymorphie tritt in der Funktion unterhaltungswert() auf. Dort rufen wir auf jedem Objekt, was Unterhaltend implementiert, die Funktion unterhaltungswert() auf. Durch die Summation der unterschiedlichen Unterhaltungswerte bekommen wir den Unterhaltungswert des gesamten Unterhaltungsprogramms. Auch die Klasse Unterhaltungsprogramm könnte wiederum Unterhaltend implementieren. So implementiert sich schnell das so genannte Composite-Pattern.

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

6.11.2 Die Mehrfachvererbung bei Schnittstellen 

Bei Klassen gibt es die Einschränkung, dass nur von einer direkten Oberklasse abgeleitet werden darf. 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. Der Unterschied zu Klassen ist jetzt, dass mehrere Schnittstellen von einer einzigen Klasse implementiert werden können. Dies wird gelegentlich als »Mehrfachvererbung in Java« bezeichnet.

Eine Disko soll nicht nur die Methode unterhaltungswert() von Unterhaltend implementieren, sondern sich auch mit anderen Diskotheken vergleichen können. Dazu gibt es schon eine passende Schnittstelle von Sun: java.lang.Comparable. Wir fordern, dass unsere Disko auch die Methode compareTo(Object) implementiert.

Listing 6.52   ve/Disko.java

package ve;

public class Disko   implements Unterhaltend, Comparable  
{
  int anzahlPersonen;
  int quadratmeter;

  public int unterhaltungswert()
  {
    return (int) (anzahlPersonen * Math.sqrt( quadratmeter ));
  }

  /**
   * Vergleicht ein anderes Disko-Objekt mit unserem aufgrund des
   * Unterhaltungswerts.
   *
   * @param   other  Die <code>Disko</code>, die sich mit uns vergleicht.
   *
   * @return  Einen Wert kleiner Null, wenn wir einen kleinen Unterhaltungswert
   *          haben als die andere Disko. 0, wenn beide gleich unterhaltend 
   *          sind. Einen Wert größer Null, wenn unsere Disko unterhaltender ist.
   *
   * @throws  <code>IllegalArgumentException</code> wenn das Argument 
   *          keine Disko ist.
   *
   * @see     java.lang.Comparable
   */
  public int compareTo( Object other )
  {
    if ( other instanceof Disko )
      return this.unterhaltungswert() - ((Disko)other).unterhaltungswert();

    throw new IllegalArgumentException( "Kann mich nur mit Diskos vergleichen" );
  }
}

Durch diese Mehrfachvererbung bekommt Disko mehrere Obertypen, so dass sich je nach Sichtweise schreiben lässt:

Object       d1 = new Disko();
Unterhaltend d2 = new Disko();
Comparable   d3 = new Disko();
Disko        d4 = new Disko();

Dabei ist über d2 die Methode compareTo() und für d3 die Methode unterhaltungswert() nicht definiert. Für d4 sind dagegen alle Methoden sichtbar.

Ein kleines Beispiel zeigt abschließend die Anwendung der Funktion compareTo().

package ve;

public class DiskoKritiker
{
  public static void main( String args[] )
  {
    Disko d1 = new Disko();
    d1.quadratmeter   = 1230; d1.anzahlPersonen =  891;

    Disko d2 = new Disko();
    d2.quadratmeter   = 2390; d2.anzahlPersonen = 1091;

    System.out.println( d1.unterhaltungswert() );  //  31248
    System.out.println( d2.unterhaltungswert() );  //  53336

    System.out.println( d1.compareTo(d2) );        // -22088
  }
}

Keine Kollisionen bei Mehrfachvererbung

Da Dilemma bei der Mehrfachvererbung von Klassen wäre, dass zwei Oberklassen die gleiche Funktion mit zwei unterschiedlichen Implementierungen vererben könnte. 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.

interface Politisch
{
    void geldHer();  
}

interface Verbrecherisch
{
    void geldHer();  
}

public class Saddam   implements Politisch, Verbrecherisch  
{
    public void geldHer()  
  {
  }
}

6.11.3 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 Telefonierend   extends Unterhaltend  
{
  double gesprächsdauer();
}

Eine Klasse, die nun Telefonierend implementiert, muss die Methoden von beiden Schnittstellen implementieren, demnach die Methode unterhaltungswert() aus Unterhaltend sowie die Methode gesprächsdauer(), die in Telefonierend selbst angegeben wurde.

6.11.4 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. Es gibt dabei einige kleine Einschränkungen.

Wir wollen an einem Beispiel sehen, wie sich die Vererbung auswirkt, wenn gleiche Bezeichner in den Unterschnittstellen erneut verwendet werden. Das nachfolgende Programm implementiert folgendes UML-Diagramm:

Hier klicken, um das Bild zu Vergrößern

Listing 6.54   VererbteSchnittstellen.java

interface Grundfarben
{
  int ROT     = 1;
  int GRÜN    = 2;
  int BLAU    = 3;
}

interface Sockenfarben extends Grundfarben
{
  int SCHWARZ = 10;
  int LILA    = 11;
}
interface Hosenfarben extends Grundfarben
{
  int LILA    = 11;
  int SCHWARZ = 20;
  int BRAUN   = 21;
}

interface Allefarben extends Sockenfarben, Hosenfarben
{
  int BRAUN  = 30;
}

public class VererbteSchnittstellen
{
  public static void main( String args[] )
  {
    System.out.println( Sockenfarben.ROT );     // 1
    System.out.println( Allefarben.ROT );       // 1
    System.out.println( Hosenfarben.SCHWARZ );  // 20

//    System.out.println( Allefarben.SCHWARZ );

    // The field name "SCHWARZ" is an ambiguous name
    //found in the types "Sockenfarben" and "Hosenfarben".

//    System.out.println( Allefarben.LILA );
  }
}

Die Definitionen der Schnittstellen können ohne Fehler übersetzt werden. Das Programm zeigt im Wesentlichen vier Eigenschaften:

6.11.5 Vordefinierte Methoden einer Schnittstelle 

Der Typ eines Objekts bei der Deklaration einer Referenz kann entweder ein Objekt oder eine Schnittstelle sein. Ist die Referenz vom Typ einer Schnittstelle, dann ist es bemerkenswert, dass der Compiler erlaubt, Methoden der Klasse Object für diese Referenz aufzurufen.

interface I
{
}

class C implements I
{
}

Erzeugen wir ein Objekt vom Typ C, so kennt C automatisch alle Methoden aus C (keine) und zusätzlich, aufgrund des impliziten extends Object, auch die Methoden aus Object. Daher lässt sich schreiben:

C ref = new C();
ref.toString();

Die Schnittstelle spielt hier noch keine Rolle. Was jedoch auch funktioniert ist Folgendes:

I ref = new C();
ref.toString();

Es ist zu erwarten, dass ref nur Methoden aus I nutzen kann und das sind keine! Da allerdings jede Klasse automatisch von Object erbt und damit die Methoden besitzt, erlaubt der Compiler Zugriff auf diese Eigenschaften. So lässt sich vereinfacht sagen, dass alle Methoden von Object erlaubt sind, auch wenn ein Interface selbst diese Methoden nicht besitzt. Jede Schnittstelle ist somit eine indirekte Erweiterung von Object.

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 definiert ist:

package java.util;

public interface Comparator
{
  int compare( Object o1, Object 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. Denn equals() ist schon eine Methode, 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.) Weiter 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 in der genauen Angabe der Funktionsweise in der Dokumentation. 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.11.6 CharSequence als Beispiel einer Schnittstelle 

Bisher kennen wir die Klassen String, StringBuffer und StringBuilder, um Zeichenketten zu speichern und weiterzugeben. Ein String ist ein Wertobjekt und ein wichtiges Hilfsmittel in Programmen, da durch diesen unveränderliche Zeichenkettenwerte repräsentiert werden, während StringBuffer und StringBuilder veränderliche Zeichenfolgen umfassen. Aber wie sieht es aus, wenn eine Teilzeichenkette gefordert ist, bei der es egal sein soll, ob das Original als String-, StringBuffer oder StringBuilder-Objekt vorliegt?

Eine Lösung ist, alles in ein String-Objekt zu konvertieren. Möchte ein Programm eine Teilfolge liefern, auf die jemand lesend zugreifen möchte, die er aber nicht verändern können soll, ist ein String zu träge. Aus den beliebigen Zeichenfolgen müsste zuerst ein String-Objekt konstruiert werden. Daher haben die Entwickler seit der Version 1.4 die Schnittstelle CharSequence eingefügt, die eine unveränderliche, nur lesbare Sequenz von Zeichen realisiert. Die Schnittstelle wird von String sowie StringBuffer und StringBuilder implementiert, so dass sich alle Zeichenketten dieser Klassen als CharSequence auszeichnen. Funktionen müssen sich also nicht mehr für konkrete Klassen entscheiden, sondern können einfach ein CharSequence-Objekt als Argument akzeptieren oder als Rückgabe weitergeben. Ein String und ein StringBuffer/StringBuilder-Objekt können zwar mehr als CharSequence vorschreibt, aber beide lassen sich als CharSequence einsetzen, wenn das »Mehr« an Funktionalität nicht benötigt wird.

Hier klicken, um das Bild zu Vergrößern

interface java.lang.  CharSequence  

char charAt( int index ) Liefert das Zeichen an der Stelle index.

int length() Gibt die Länge der Zeichensequenz zurück.

CharSequence subSequence( int start, int end ) Liefert eine neue CharSequence von start bis end.

String toString() Gibt einen String der Sequenz zurück. Die Länge des toString()-Strings entspricht genau der Länge der Sequenz.

void giveMeAText( CharSequence s )
{
  ...
}

void giveMeAText( String s )
{
  ...
}
void giveMeAText( StringBuffer s )
{
  void giveMeAText( new String(s) );  // oder Ähnliches
}

Anwendung von CharSequence in String

In den Klassen String und StringBuffer existiert eine Methode subSequence(), die ein CharSequence-Objekt liefert. Die Signatur ist in beiden Fällen die gleiche. Die Funktion macht im Prinzip nichts anderes als ein substring(begin, end).

CharSequence subSequence( int beginIndex, int endIndex ) Liefert eine neue Zeichensequenz von String beziehungsweise StringBuffer.

Die Implementierung sieht so aus, dass mit substring() ein neuer Teilstring zurückgeliefert wird. Das ist eine einfache Lösung, aber nicht unbedingt die schnellste. Für String-Objekte ist das Erzeugen von Substrings ziemlich schnell, da die Methode speziell optimiert ist. Da Strings unveränderlich sind, wird einfach das gleiche char-Feld wie im Original-String verwendet, nur eine Verschiebung und ein Längenwert werden angepasst.

6.11.7 Die Schnittstelle Iterable 

Dass Felder durch die erweiterte for-Schleife durchlaufen werden können, ist nur ein Teil. Als Typ rechts vom Doppelpunkt kann alles stehen, dessen Klassen die Schnittstelle Iterable implementieren. Sie schreibt nur die Existenz einer Funktion iterator() vor, die einen java.util.Iterator liefert.

interface java.lang.  Iterable<T>  

Iterator<T> iterator() Liefert einen Iterator, der über alle Elemente vom Typ T iteriert.

Viele Klasse implementieren schon diese Schnittstelle, so dass mit dem erweiterten for durch Ergebnismengen iteriert werden kann. In erster Linie handelt es sich um Datenstrukturen. Dazu kommt noch das Feld, welches zwar nicht direkt als Klasse sichtbar ist, aber Iterable passend implementiert.

Einen eigenen Iterable

Möchten wir selbst rechts neben dem Doppelpunkt vom erweiterten for stehen, müssen wir ein Objekt angeben, dessen Klassse Iterable implementiert und somit eine iterator()-Funktion besitzt. iterator() muss dann einen passenden Iterator zurückgeben. Der wiederum muss die Methoden hasNext() und next() implementieren, um das nächste Element in der Aufzählung zu geben und das Ende anzuzeigen. Zwar schreibt der Iterator auch remove() vor, doch das wird leer implementiert.

Unser Beispiel soll einen praktischen Iterable implementieren, um über Worte eines Satzes zu gehen. Als grundlegende Implementierung dient der StringTokenizer, der über hasToken()die nächsten Teilfolgen und über hasMoreTokens() meldet, ob weiteren Tokens ausgelesen werden können.

Beginnen wir mit dem ersten Teil, der Klasse WordIterable, die erst einmal Iterable implementieren muss, um auf der rechten Seite vom Punkt stehen zu können. Dann muss dieses Exemplar über iterator() einen Iterator zurückgeben, der über alle Wörter läuft. Diese Iterator kann als eigene Klasse implementiert werden, doch wir wählen hier den Weg, dass die Klasse WordIterable so implementiert ist, dass sie Iterable und Iterator gleichzeitig ist; daher ist nur ein Exemplar nötig.

Listing 6.56   WordIterableDemo.java

import java.util.Iterator;
import java.util.StringTokenizer;

class WordIterable implements Iterable, Iterator
{
  private StringTokenizer st;

  public WordIterable( String s )
  {
    st = new StringTokenizer( s );
  }

  // Methode vom Iterable

  public Iterator iterator()
  {
    return this;
  }

  // Methoden vom Iterator

  public boolean hasNext()
  {
    return st.hasMoreTokens();
  }

  public Object next()
  {
    return st.nextToken();
  }

  public void remove() { }
}

Im Beispiel

public class WordIterableDemo
{
  public static void main( String args[] )
  {
    String s = "Am Anfang war das Wort - 
am Ende die Phrase. (Stanislaw Jerzy Lec)";

    for ( Object word : new WordIterable(s) )
    System.out.println( word );
  }
}

Die Konstruktion

for ( Object word : new WordIterator(s) )
  System.out.println( words );

wird vom (Eclipse) Compiler umgebaut zu

Object word;
WordIterable worditerable;
for ( Iterator iterator = (worditerable = new WordIterable(s)).iterator();
iterator.hasNext(); )
{
  word = iterator.next();
  System.out.println( word );
}

¹   Äquivalent zu denen in Objective-C