Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Ein Interface ist ein Vertrag. Es sagt: "Wer mich implementiert, MUSS diese Methoden anbieten." Wie ein Vertrag mit der Versicherung — egal welche Versicherung du nimmst, sie verspricht dir bestimmte Leistungen. Das WIE ist offen, das WAS ist fest.
In Java der Schlüssel zu lockerer Kopplung und Mehrfach-Vererbung (die mit extends verboten ist). Klausur-Klassiker: Interface vs. abstrakte Klasse, multiple implementation, Polymorphie über Interface-Referenzen.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Ein Interface ist ein Vertrag. Es sagt: "Wer mich implementiert, MUSS diese Methoden anbieten." Wie ein Vertrag mit der Versicherung — egal welche Versicherung du nimmst, sie verspricht dir bestimmte Leistungen. Das WIE ist offen, das WAS ist fest.
In Java der Schlüssel zu lockerer Kopplung und Mehrfach-Vererbung (die mit extends verboten ist). Klausur-Klassiker: Interface vs. abstrakte Klasse, multiple implementation, Polymorphie über Interface-Referenzen.
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.
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.
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.
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.
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.
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.
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.
| Eigenschaft | Interface | Abstrakte Klasse |
|---|---|---|
| Mehrfach-Vererbung | ✅ (mehrere implements) | ❌ (nur 1 extends) |
| Felder | nur public static final (Konstanten) | beliebige Felder, alle Sichtbarkeiten |
| Methoden | abstrakt + default + static | abstrakt + konkret + private |
| Konstruktor | ❌ verboten | ✅ erlaubt (für Subklassen) |
| State (Felder mit Wert) | ❌ kein State | ✅ State möglich |
| Schlüsselwort | implements | extends |
| Sichtbarkeit Methoden | implizit public | beliebig |
Faustregel: Erst Interface versuchen. Nur abstrakte Klasse, wenn du echten Code mehrfach teilen willst (Konstruktor, State, gemeinsame Helper).
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()
Das ist dynamische Bindung: Welche Methode aufgerufen wird, entscheidet sich zur Laufzeit anhand des tatsächlichen Objekt-Typs, nicht der Variablen-Deklaration. Klausur-Frage Standard: "Welche Methode wird aufgerufen?" — Antwort hängt von new ...(), nicht von der Variable.
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 — strenger als das Interface darf nicht sein.
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.
1. public bei Implementierung vergessen. Im Interface ist die Methode implizit public. Wenn du in der Klasse void starten() (ohne public) schreibst, ist das package-private — strenger als das Interface erlaubt → Compile-Error.
2. Interface mit new instanziieren. Fahrzeug f = new Fahrzeug(); geht nicht (außer mit anonymer Klasse). Du brauchst eine konkrete Implementierer-Klasse.
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()).
3 Szenarien, jedes zeigt das UML-Diagramm + Code parallel:
extendsBeobachte wie sich die Pfeile (gestrichelt = implements, durchgezogen = extends) und der Code ändern.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
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.
6 Aufgaben zu Interface-Syntax, Multi-Implementation, Polymorphie.
Klausurfragen mit Lösungen (6)
Antwort: Ein Interface definiert nur Methoden-Signaturen (vor Java 8)
Erklärung: Ein klassisches Interface (vor Java 8) enthält nur abstrakte Methoden-Signaturen. Konstruktoren sind verboten, eine Klasse darf beliebig viele Interfaces implementieren, und Interfaces erben höchstens von anderen Interfaces — nie von Klassen.
Antwort: implements
Erklärung: `class Auto implements Fahrzeug` — implements für Interfaces, extends für Klassen. Beides zusammen: `class Auto extends Fahrzeug implements Bremsbar, Lenkbar`.
Antwort: Wahr
Erklärung: RICHTIG. `class Ente extends Tier implements Schwimmen, Fliegen` ist erlaubt. Im Gegensatz dazu darf eine Klasse nur EINE Oberklasse via extends haben. Genau deshalb sind Interfaces das Java-Mittel für Mehrfach-Vererbung.
Typ: Wahr/Falsch
Antwort: Falsch
Erklärung: FALSCH. Interfaces können nicht direkt instanziiert werden — sie haben keine Implementierung. Du brauchst eine konkrete Klasse: `Fahrzeug f = new Auto();`. Ausnahme: anonyme Klassen mit `new Fahrzeug() { ... };` (aber da gibst du die Implementierung sofort mit).
Typ: Wahr/Falsch
Richtige Antworten: Interface erlaubt Mehrfach-Vererbung, abstrakte Klasse nicht; Abstrakte Klasse kann Konstruktor haben, Interface nicht; Abstrakte Klasse kann konkrete Methoden enthalten; Default-Methoden gibt es nur in Interfaces
Erklärung: Richtig: Multi-Inheritance nur via Interface, Konstruktor nur in abstrakter Klasse, konkrete Methoden in abstrakter Klasse, Default-Methoden nur in Interfaces. Falsch: Interface hat KEIN State (nur Konstanten via public static final), und keine der beiden kann direkt instanziiert werden.
Typ: Multi-Select
Zuordnungen:
Erklärung: Standard-Vergleich. Wenn du dies auswendig hast, sitzt die Klausur-Frage 'Interface vs. abstract class' in 30 Sekunden.
Typ: Zuordnung
Klausurfragen mit Lösungen (6)
Antwort: public
Erklärung: Methoden in Interfaces sind implizit `public abstract`. Du musst beim Implementieren in der Klasse explizit `public` schreiben — strenger geht nicht (das wäre eine Sichtbarkeits-Reduktion und Compile-Error).
Antwort: public static final (Konstanten)
Erklärung: Felder in Interfaces sind IMMER public static final, egal ob du es hinschreibst oder nicht. Konstanten also. Anti-Pattern in modernem Java (besser Enum/final class), aber Klausur-Wissen.
Antwort: Wahr
Erklärung: RICHTIG, ausser die Klasse wird als `abstract` markiert. Eine konkrete Klasse MUSS alle abstrakten Methoden des Interfaces implementieren. Sonst Compile-Error: 'class is not abstract and does not override abstract method ...'
Typ: Wahr/Falsch
Lösungen pro Lücke:
Erklärung: Standard-Syntax. `class A implements I1, I2, I3 { ... }` mit allen Methoden public abstract (im klassischen Sinne, vor Java 8 Default-Methoden).
Typ: Lückentext
Antwort: Compile-Fehler — Klasse C muss `m()` selbst überschreiben
Erklärung: Diamond-Konflikt bei Default-Methoden: Java zwingt dich, in C ein eigenes `m()` zu definieren. Du kannst aber via `A.super.m()` oder `B.super.m()` eine der beiden konkret aufrufen.
Richtige Reihenfolge:
Erklärung: Java-Syntax-Reihenfolge ist FEST: `class <Name> extends <Klasse> implements <I1, I2> { ... }`. `extends` IMMER vor `implements`. Tauschen → Compile-Error.
Typ: Reihenfolge
| Wann nutzen? |
| Vertrag, lose Kopplung, Multi-Inheritance |
| gemeinsamer Code-Vorrat, Template-Method |