Interfaces.

Ein Interface ist ein Vertrag. Es legt fest, welche Methoden eine Klasse anbieten muss, ohne vorzuschreiben, wie sie umgesetzt werden. Wie ein Stecker-Standard (USB-C): egal welches Gerät dahintersteckt, es muss exakt dieselben Pins in derselben Anordnung haben, sonst passt der Stecker nicht. Das Wie (was im Gerät passiert) ist offen, das Was (die Form des Steckers, also die Schnittstelle) ist fest. Genauso können in Java Auto und Fahrrad beide das Interface Fahrbar implementieren, obwohl sie keine gemeinsame Oberklasse brauchen, jeder fährt nur auf seine Weise.

Wozu brauchst du das? Ein Interface ist in Java der Schlüssel zu loser Kopplung (Code hängt am Vertrag, nicht an einer konkreten Klasse) und zu Mehrfach-Vererbung von Typ/Vertrag (mit extends ist mehr als eine Oberklasse verboten, mit implements darf eine Klasse beliebig viele Interfaces erfüllen). Wichtig zur Abgrenzung: gemeint ist Mehrfachvererbung von Typ/Vertrag, nicht von Feldern oder Klassen-Implementierung, ein Interface vererbt keinen Zustand und keinen geteilten Konstruktor-Code. Klassisch enthält ein Interface nur Signaturen ohne Code, seit Java 8 dürfen Interfaces aber auch default-Methoden mit fertiger Implementierung mitbringen. Klausur-Klassiker: Interface vs. abstrakte Klasse, Multi-Implementation, Polymorphie über Interface-Referenzen.

Die Idee in einem Satz

Interface: Definiert WAS eine Klasse können muss (Methoden-Signaturen), nicht WIE sie es macht (keine Implementierung).

interface Sortierbar {
    int compareTo(Sortierbar other);
}

Wer Sortierbar implementieren will, MUSS compareTo anbieten. Wie genau sortiert wird (nach Name, Note, Matrikelnummer), ist Sache der Klasse.

Visuell sieht die implements-Beziehung in UML so aus (gestrichelte Linie + Pfeil = "implementiert"):

        <<interface>>
         Sortierbar
        +compareTo()
              ^
              ¦   gestrichelte Linie = implements
      ........¦........
      ¦               ¦
   Student           Buch
   +compareTo()      +compareTo()

Merkregel fürs Diagramm: gestrichelte Linie = implements (Klasse erfüllt Interface), durchgezogene Linie = extends (Klasse erbt von Klasse). Den interaktiven UML-Visualizer mit allen drei Szenarien findest du weiter unten.

Und damit der wichtigste Klausur-Vergleich sofort sitzt, hier die Kurzfassung (die volle Tabelle kommt später):

Beispiel: ohne vs. mit Interface

Ohne Interface (rigide Kopplung)

class SortierAlgorithmus {
    void sortiere(Student[] studenten) {
        // ... vergleicht direkt student.note
    }
}

class AnderesSortierAlgorithmus {
    void sortiere(Buch[] buecher) {
        // ... vergleicht direkt buch.titel
    }
}

Für jeden Datentyp eine eigene Sortier-Klasse. Nicht wiederverwendbar.

Mit Interface (flexible Kopplung)

interface Sortierbar {
    int compareTo(Sortierbar other);
}

class Student implements Sortierbar {
    int note;
    public int compareTo(Sortierbar other) {
        return this.note - ((Student) other).note;
    }
}

class Buch implements Sortierbar {
    String titel;
    public int compareTo(Sortierbar other) {
        return this.titel.compareTo(((Buch) other).titel);
    }
}

class Sortierer {
    static void sortiere(Sortierbar[] items) {
        // funktioniert für ALLES, was Sortierbar ist
    }
}

Eine Sortier-Logik, viele sortierbare Klassen. Das ist Polymorphie via Interface.

Praxis-Hinweis (Best Practice): Der Cast ((Student) other) ist hier didaktisch vereinfacht, er kann zur Laufzeit eine ClassCastException werfen, falls other doch kein Student ist. In echtem Code nutzt man das generische Comparable<Student> aus der Java-Standardbibliothek: class Student implements Comparable<Student> mit public int compareTo(Student other). Dann ist der Vergleich typsicher und der Cast entfällt komplett (so empfiehlt es auch Bloch, Effective Java, Item 14). Wir bleiben oben beim ungenerischen Interface, um nur das Prinzip zu zeigen.

Interface deklarieren und implementieren

interface Fahrzeug {
    void starten();
    void stoppen();
    int getMaxGeschwindigkeit();
}

class Auto implements Fahrzeug {
    public void starten() {
        System.out.println("Motor an");
    }
    public void stoppen() {
        System.out.println("Motor aus");
    }
    public int getMaxGeschwindigkeit() {
        return 200;
    }
}

Pflicht: Alle Methoden des Interfaces müssen implementiert werden. Wenn auch nur eine fehlt → Compile-Error, ausser die Klasse ist abstract.

Multi-Implementation: das Killer-Feature

Java erlaubt Einfach-Vererbung mit extends (max. 1 Oberklasse), aber Mehrfach-Implementierung mit implements:

interface Schwimmen {
    void schwimmen();
}

interface Fliegen {
    void fliegen();
}

class Ente extends Tier implements Schwimmen, Fliegen {
    public void schwimmen() { System.out.println("paddel paddel"); }
    public void fliegen() { System.out.println("flatter flatter"); }
}

Die Ente erbt von Tier und implementiert 2 Interfaces. Das geht mit extends nicht (Diamond-Problem), aber mit Interfaces problemlos.

Default-Methoden (Java 8+)

Seit Java 8 dürfen Interfaces auch Default-Implementierungen anbieten. Damit kannst du Interfaces erweitern, ohne alle bestehenden Implementierer zu brechen:

interface Fahrzeug {
    void starten();

    // Default-Methode mit Implementierung
    default void hupe() {
        System.out.println("Hup hup!");
    }
}

class Auto implements Fahrzeug {
    public void starten() { /*...*/ }
    // hupe() musst du nicht implementieren, wird von Default geerbt
}

Klausur-Falle: Default-Methoden lockern die "nur Vertrag"-Regel. Manche Hochschulen behandeln Interfaces noch klassisch (nur Signaturen), prüfe dein Skript.

Private Interface-Methoden (Java 9+)

Seit Java 9 dürfen Interfaces zusätzlich private Methoden als interne Helfer enthalten. Sie sind dazu da, gemeinsamen Code mehrerer default- oder static-Methoden zu bündeln, ohne ihn nach außen sichtbar zu machen:

interface Logger {
    default void info(String msg)  { log("INFO", msg); }
    default void error(String msg) { log("ERROR", msg); }

    // private Helper, NICHT Teil der öffentlichen API
    private void log(String level, String msg) {
        System.out.println("[" + level + "] " + msg);
    }
}

Wichtig: Private Interface-Methoden gehören nicht zur öffentlichen API, sie können nur innerhalb des Interfaces selbst aufgerufen werden, eine implementierende Klasse sieht sie gar nicht und kann sie nicht überschreiben. Es ist also kein neuer Vertrags-Bestandteil, sondern reine interne Strukturierung der Default-Methoden.

Quelle/Version: Private Interface-Methoden wurden mit Java 9 eingeführt (JEP 213, "Milling Project Coin"). Spezifiziert in der Java Language Specification §9.4 (Methodendeklarationen in Interfaces); eine kompakte Einführung bietet das Oracle-Tutorial-Kapitel zu Default- und privaten Methoden. Da viele Hochschulen noch auf Java 8 oder klassischen Interfaces aufsetzen, prüfe dein Skript, ob dieses Feature klausurrelevant ist.

Konstanten in Interfaces

Felder in Interfaces sind implizit public static final (Konstanten):

interface MathKonstanten {
    double PI = 3.14159;
    double E = 2.71828;
}

class Rechner implements MathKonstanten {
    double umfang(double r) {
        return 2 * PI * r;  // direkter Zugriff
    }
}

In modernen Java-Codes ist das Anti-Pattern (Konstanten gehören in final class-Utility-Klassen oder Enums), aber Klausur kann fragen, was die Sichtbarkeit ist.

Warnung: Nutze Interface-Konstanten sparsam. In Anfängerprojekten werden sie oft als allgemeiner globaler Speicher missbraucht (jede Klasse implementiert das Interface nur, um an die Werte zu kommen). Für zusammengehörige Konstanten ist meist eine finale Utility-Klasse (final class MathKonstanten mit private Konstruktor) oder ein enum sauberer, weil dort der Vertrags-Gedanke des Interfaces nicht verwässert wird.

Interface vs. Abstrakte Klasse, der ewige Klausur-Klassiker

Faustregel: Erst Interface versuchen. Nur abstrakte Klasse, wenn du echten Code mehrfach teilen willst (Konstruktor, State, gemeinsame Helper).

Polymorphie via Interface-Referenz

Du kannst eine Variable vom Interface-Typ deklarieren und beliebige Implementierer zuweisen:

Fahrzeug f;
f = new Auto();
f.starten();    // ruft Auto.starten()

f = new Motorrad();
f.starten();    // ruft Motorrad.starten()

Java entscheidet erst zur Laufzeit, welche Methode passt, das nennt man dynamische Bindung (oder Late Binding). Welche Methode aufgerufen wird, hängt also am tatsächlichen Objekt-Typ (new ...()), nicht am deklarierten Typ der Variablen. Klausur-Frage Standard: "Welche Methode wird aufgerufen?", Antwort hängt von new ...(), nicht von der Variable.

Klausur-Faustregeln

1. Interface = Vertrag, kein State. Felder sind public static final (Konstanten), keine Instanzvariablen.

2. implements für Interfaces, extends für Klassen. Bei mehreren Interfaces durch Komma trennen: implements A, B, C.

3. Methoden im Interface sind implizit public. Bei der Implementierung MUSST du explizit public schreiben, die Sichtbarkeit darf gegenüber dem Interface nicht eingeschränkt (weniger offen) werden.

4. Default-Methoden sind nicht statisch. Sie werden auf Instanzen aufgerufen wie normale Methoden. Statische Methoden im Interface (static Schlüsselwort) gibts seit Java 8 auch, aber separat.

5. Polymorphie funktioniert über Interface-Referenz. List<Integer> l = new ArrayList<>(); ist Standard-Java-Stil, Variable vom Interface-Typ, Objekt von konkreter Klasse.

Häufige Stolpersteine

1. public bei Implementierung vergessen. (TOP-Falle) Im Interface ist die Methode implizit public. Wenn du in der Klasse void starten() (ohne public) schreibst, ist das package-private, also weniger sichtbar als vom Interface gefordert → Compile-Error (eine Implementierung darf die Sichtbarkeit nie einschränken, nur beibehalten). Das ist der mit Abstand häufigste Klausur-Fehler bei Interfaces.

2. Interface mit new instanziieren. (TOP-Falle) Fahrzeug f = new Fahrzeug(); geht nicht (außer mit anonymer Klasse). Du brauchst eine konkrete Implementierer-Klasse. Diese Falle wird in Klausuren extrem gern als Ankreuz-Distraktor versteckt.

3. Methoden-Signatur abweichen lassen. Wenn das Interface int compareTo(Sortierbar) vorgibt und du int compareTo(Object) schreibst, implementierst du das Interface nicht. Bei Signaturmismatch wird die Methode überladen statt überschrieben.

4. Konstruktoren im Interface erwarten. Interfaces haben keine Konstruktoren. Wenn du Setup brauchst, mach es in der Implementierer-Klasse.

5. Default- und abstract-Methoden mit gleicher Signatur in 2 Interfaces. Bei Multi-Implementation müsstest du selbst überschreiben und entscheiden welche Default-Methode du nehmen willst (Interface.super.methode()).

Klausur-Beispielaufgabe

Beispiel (typischer Klausur-Stil, zur Übung konstruiert).

Gegeben sind ein Interface und zwei Klassen:

interface Zahlbar {
    double betrag();
}

class Rechnung implements Zahlbar {
    private double summe;
    public Rechnung(double summe) { this.summe = summe; }
    public double betrag() { return summe; }
}

abstract class Dokument {
    abstract String titel();
}

(a) Warum ist Zahlbar z = new Zahlbar(); ein Fehler, Zahlbar z = new Rechnung(99.0); aber erlaubt? (b) Die Klasse Mahnung soll sowohl ein Dokument sein als auch Zahlbar. Schreibe den Kopf der Klassendeklaration (nur die erste Zeile, ohne Body). (c) Eine Methode double summe(Zahlbar[] posten) addiert die Beträge aller Elemente. Warum funktioniert sie für ein Array, das Rechnung- und Mahnung-Objekte gemischt enthält? Wie heißt das zugrunde liegende Prinzip?

Lösung:

• (a) Zahlbar ist ein Interface ohne Implementierung, ein Interface lässt sich nicht direkt mit new instanziieren. new Rechnung(99.0) erzeugt dagegen ein konkretes Objekt; weil Rechnung Zahlbar implementiert, darf die Referenz vom Interface-Typ Zahlbar sein (Polymorphie über Interface-Referenz).
• (b) class Mahnung extends Dokument implements Zahlbar { , extends (genau eine Klasse) steht immer vor implements (beliebig viele Interfaces).
• (c) Alle Elemente sind vom statischen Typ Zahlbar und bieten daher garantiert betrag() an. Zur Laufzeit ruft Java über dynamische Bindung die jeweils passende Implementierung (Rechnung.betrag() oder Mahnung.betrag()) auf. Das Prinzip heißt Polymorphie (über eine Interface-Referenz).

Interface-UML-Visualizer

3 Szenarien, jedes zeigt das UML-Diagramm + Code parallel:

1. Einfaches Interface, eine Klasse implementiert ein Interface
2. Multi-Implementation, eine Klasse implementiert mehrere Interfaces
3. Interface-Hierarchie, ein Interface erbt von einem anderen via extends

Schalte direkt auf Szenario Multi-Implementation (Ente), dort siehst du auf einen Blick, was implements Schwimmen, Fliegen bedeutet. Beobachte wie sich die Pfeile (gestrichelt = implements, durchgezogen = extends) und der Code ändern.

Klausur-Tipp: UML-Diagramme in Java-Klausuren nutzen gestrichelte Pfeile für implements und durchgezogene Pfeile für extends. Wenn du es siehst, weißt du sofort die Beziehung. Frage in der Prüfung: "Welche Methoden muss Ente implementieren?", Antwort: alle abstrakten Methoden aller Interfaces, die sie implementiert + Schwimmen + Fliegen + Tier-Methoden, die nicht in Tier implementiert sind.

Code-Stepper: Schritt für Schritt

Drei Demos zum Durchklicken. Klick Step oder Auto und beobachte, wie sich Variablen, Aufruf-Ziel und Konsole pro Schritt ändern.

1. implements: der Vertrag zwingt zur Implementierung

Auto implementiert Fahrzeug und muss daher jede Interface-Methode mit public ausprogrammieren. Wir verfolgen einen starten()-Aufruf.

2. Polymorphie + dynamische Bindung

Dieselbe Variable vom Interface-Typ Fahrzeug zeigt nacheinander auf verschiedene Objekte. Welche starten()-Methode läuft, entscheidet sich erst zur Laufzeit anhand des echten Objekt-Typs, nicht anhand der Variablen-Deklaration.

3. Default-Methode: geerbt ohne eigene Implementierung

Seit Java 8 darf ein Interface eine default-Methode mitbringen. Auto implementiert nur starten() selbst, hupe() wird aus dem Interface geerbt, ohne dass die Klasse sie schreibt.

Klausur-Tipp: Achte bei Tracing-Aufgaben immer auf den tatsächlichen Typ hinter der Interface-Variablen (new ...()), nicht auf den deklarierten Typ. Genau dort versteckt sich die typische Polymorphie-Frage "Welche Methode wird aufgerufen?".

Interfaces, Praxis-Übung

6 Aufgaben zu Interface-Syntax, Multi-Implementation, Polymorphie.