Abstrakte Klassen und Interfaces

In den letzten Lektionen hast du Vererbung (L5) und Polymorphismus (L6) gelernt. Beides funktioniert nur dann gut, wenn man weiß welche Methoden eine Klasse haben muss. Genau das machen abstrakte Klassen und Interfaces: sie definieren Verträge ohne konkrete Implementierung.

Diese Lektion klärt den oft verwechselten Unterschied zwischen abstrakter Klasse und Interface, zeigt wann du welches brauchst, und behandelt moderne Entwicklungen wie Default-Methoden in Java 8+. Eines der Themen, das in Bewerbungsgesprächen garantiert abgefragt wird.

1) Das Problem mit normalen Klassen

In L6 hatten wir eine Tier-Klasse mit Methode laut_geben(), die in der Basis-Implementierung nur "???" ausgab. Das ist nicht ideal:

Niemand sollte je ein „pures" Tier erzeugen können – es existiert nur als abstrakter Begriff
Die Methode laut_geben() hat keine sinnvolle Default-Implementierung – jede Unterklasse muss sie definieren
Es gibt keine Garantie, dass jede Unterklasse die Methode überschreibt – wenn nicht, kommt "???"

Die Lösung: Abstraktion. Eine abstrakte Klasse kann nicht direkt instanziiert werden, und kann Methoden ohne Implementierung haben, die jede Unterklasse zwingend ausfüllen muss.

2) Abstrakte Klassen

Eine abstrakte Klasse ist eine Klasse, die mit dem Schlüsselwort abstract markiert ist. Du kannst sie nicht mit new erzeugen – nur als Basisklasse nutzen. Sie kann:

Konkrete Methoden mit voller Implementierung enthalten (wie normale Klassen)
Abstrakte Methoden ohne Implementierung – nur Signatur, kein Body
Felder (Attribute) – auch private, mit Zustand
Einen Konstruktor (der aber nur von Unterklassen aufgerufen wird)

Tier.javaJava – abstrakte Klasse

1public abstract class Tier {
2    protected String name;
3
4    public Tier(String name) {
5        this.name = name;
6    }
7
8    // abstrakte Methode - kein Body!
9    public abstract void laut_geben();
10
11    // konkrete Methode - normal implementiert
12    public void schlafen() {
13        System.out.println(name + " schläft");
14    }
15}
16
17// Tier t = new Tier(...)  ← FEHLER! abstrakt = nicht instanziierbar
18
19public class Hund extends Tier {
20    public Hund(String name) { super(name); }
21
22    @Override
23    public void laut_geben() {        // MUSS implementiert werden
24        System.out.println("Wuff!");
25    }
26}

Sobald eine Klasse nur eine abstrakte Methode hat, ist sie selbst auch abstrakt. Wenn Hund die laut_geben() nicht überschreiben würde, müsste Hund selbst abstract markiert werden.

In Python erreicht man das mit dem ABC-Modul (Abstract Base Class):

tier.pyPython

1from abc import ABC, abstractmethod
2
3class Tier(ABC):                  # erbt von ABC
4    def __init__(self, name):
5        self.name = name
6
7    @abstractmethod
8    def laut_geben(self):           # abstrakt
9        pass
10
11    def schlafen(self):             # konkret
12        print(f"{self.name} schläft")

3) Interfaces

Ein Interface ist ein noch reduzierteres Konzept: es definiert nur Methoden-Signaturen ohne Implementierung. Kein Konstruktor, kein Zustand, keine Felder (zumindest klassisch). Pur ein Vertrag:

Interface = Vertrag, der von Klassen erfüllt wird

interface Zahlbar

+ double berechneBetrag()

+ String getBeschreibung()

+ Date getFaelligkeit()

↓

drei verschiedene Klassen erfüllen den Vertrag:

class Rechnung

implementiert berechneBetrag mit Steuern, Beschreibung als Rechnungsnummer

class Gehalt

berechneBetrag = Grund + Boni, Beschreibung als Monat/Jahr

class Abonnement

berechneBetrag = Monatspreis, Beschreibung als Service-Name

Das Interface sagt nur „du musst diese Methoden anbieten". Die Klassen sind völlig frei in der Implementierung und können untereinander komplett unterschiedlich sein. Polymorphismus (siehe L6) wird über das Interface möglich – jede dieser Klassen kann als Zahlbar verarbeitet werden.

interface.javaJava

1public interface Zahlbar {
2    double berechneBetrag();      // implizit public abstract
3    String getBeschreibung();
4    Date getFaelligkeit();
5}
6
7public class Rechnung implements Zahlbar {
8    public double berechneBetrag() { return netto * 1.19; }
9    public String getBeschreibung() { return rechnungsnr; }
10    public Date getFaelligkeit() { return faellig; }
11}

Java nutzt implements für Interfaces (nicht extends wie für Klassen). Eine Klasse kann nur eine Klasse erweitern, aber beliebig viele Interfaces implementieren. Das umgeht das Diamond-Problem (siehe L5).

4) Direkter Vergleich

Die zwei Konzepte überschneiden sich teilweise, sind aber strukturell unterschiedlich. Hier eine Übersicht der Unterschiede:

Abstract Class vs. Interface

abstract Abstrakte Klasse

Konkrete Methoden möglich ✓ ja

Abstrakte Methoden möglich ✓ ja

Felder/Attribute (Zustand) ✓ ja

Konstruktor ✓ ja

Sichtbarkeit der Methoden frei ✓ ja

Erbe von mehreren? ✗ nein (Java)

Direkt instanziierbar? ✗ nein

interface Interface

Konkrete Methoden ~ ab Java 8 (default)

Abstrakte Methoden ✓ ja

Felder (Zustand) ~ nur Konstanten (public static final)

Konstruktor ✗ nein

Sichtbarkeit ~ alle implizit public

Mehrfach-Implementierung ✓ ja, viele Interfaces

Direkt instanziierbar? ✗ nein

Die Grenzen verschwimmen seit Java 8 etwas: Interfaces können default-Methoden mit Implementierung haben. Trotzdem bleibt der grundsätzliche Unterschied: abstrakte Klassen halten Zustand, Interfaces nur Verhalten.

5) Default-Methoden in Java 8+

Seit Java 8 dürfen Interfaces auch Default-Implementierungen für Methoden haben. Das wurde eingeführt, damit man bestehende Interfaces erweitern kann, ohne alle Implementierungen zu brechen:

default.javaJava 8+

1public interface Begruessbar {
2    String getName();
3
4    default void begruessen() {       // Default-Implementierung!
5        System.out.println("Hallo " + getName());
6    }
7}
8
9// Klasse muss nur getName implementieren - begruessen kommt automatisch:
10class Person implements Begruessbar {
11    private String name;
12    public String getName() { return name; }
13}

Damit nähern sich Interfaces den abstrakten Klassen an. Java hat zusätzlich seit Version 9 auch private-Methoden in Interfaces, seit Version 15 auch static-Helper-Methoden. Aber Achtung: Interfaces können weiterhin keinen Zustand haben. Der Hauptunterschied bleibt.

6) Wann was nehmen?

Die wichtigste Frage in der Praxis: nehme ich abstrakte Klasse oder Interface? Hier ein Entscheidungsbaum:

Entscheidungshilfe: abstrakte Klasse oder Interface?

1. Brauchst du gemeinsamen Zustand (Felder)?

Wenn ja → Abstrakte Klasse. Interfaces können keine echten Felder halten.

↓

2. Soll eine Klasse mehrere „Rollen" annehmen können?

Wenn ja → Interface(s). Eine Klasse kann nur eine abstrakte Klasse erweitern, aber viele Interfaces implementieren.

↓

3. Beschreibst du eine „is-a"-Hierarchie?

Wenn ja → Abstrakte Klasse. „Dackel ist-ein Hund" – Vererbungs-Beziehung. Bei „can-do"-Verhalten ist Interface besser.

↓

4. Soll der Vertrag stabil bleiben, Implementierung variabel?

Wenn ja → Interface. Z.B. List-Interface in Java – viele Implementierungen (ArrayList, LinkedList) gleichen Vertrag.

↓

Im Zweifel: Interface. Bietet mehr Flexibilität und vermeidet Diamond-Problem.

Java-Bibliotheks-Beispiele: Collection, Iterable, Comparable, Runnable – alles Interfaces. AbstractList, AbstractMap – abstrakte Klassen die das Interface teilweise vorimplementieren. Dieses Muster (Interface + Abstract-Helper) ist sehr verbreitet.

7) Typische Use-Cases

Wofür typisch genutzt?

Abstrakte Klasse

Wenn mehrere Klassen viel gemeinsamen Code haben und nur Details verschieden sind. Z.B. AbstractCar mit gemeinsamen Methoden, SportsCar und SUV als Spezialisierungen.

Interface

Wenn völlig unterschiedliche Klassen dieselbe Fähigkeit haben sollen. Printable, Comparable, Iterable – Verhalten quer durch verschiedene Domänen.

Template Method Pattern

Abstrakte Klasse definiert Skelett-Algorithmus, Unterklassen füllen Lücken aus. Klassisches Design Pattern (mehr in K49).

Strategy Pattern

Interface definiert austauschbare Strategie, Klassen sind konkrete Varianten. Sehr häufig im professionellen Code (mehr in K49).

Framework-Hooks

Frameworks (Spring, Django) liefern abstrakte Klassen die du erweiterst. Lifecycle-Methoden sind vorgegeben, deine Logik kommt rein.

Marker-Interfaces

Interfaces ohne Methoden – nur als „Markierung". Serializable, Cloneable in Java. Sagen dem System: „dieses Objekt kann das".

8) Python: hat Python überhaupt Interfaces?

Python hat keine echten Interfaces als Sprach-Feature. Stattdessen gibt's drei verschiedene Wege:

Duck Typing: einfach davon ausgehen, dass das Objekt die Methoden hat. Wenn nicht, fliegt's zur Laufzeit (siehe L6).
ABC + abstractmethod: abstrakte Klassen, die als Interface-Ersatz fungieren.
typing.Protocol (Python 3.8+): „strukturelle Subtypen" – Klassen die die richtigen Methoden haben, ohne explizit zu erben.

protocol.pyPython 3.8+

1from typing import Protocol
2
3class Zahlbar(Protocol):
4    def berechneBetrag(self) -> float: ...
5    def getBeschreibung(self) -> str: ...
6
7# JEDE Klasse mit diesen Methoden ist automatisch Zahlbar
8# Keine explizite Vererbung nötig!

9) JavaScript / TypeScript

JavaScript hat klassisch keine Interfaces – die Sprache ist dynamisch. TypeScript bringt aber starkes Interface-Konzept:

interface.tsTypeScript

1interface Person {
2    name: string;
3    alter: number;
4    begruessen(): void;
5}
6
7class Mitarbeiter implements Person {
8    constructor(public name: string, public alter: number) {}
9    begruessen() { console.log("Hi!"); }
10}

TypeScript-Interfaces sind strukturell – jedes Objekt mit den richtigen Properties ist automatisch ein Person. Das ist eine Mischung aus Pythons Duck Typing und Javas explizitem Vertrag. Mehr in K42b JavaScript.

10) Häufige Klausurfragen

Was in IHK-Prüfungen und Bewerbungsgesprächen zu Interfaces und abstrakten Klassen gefragt wird:

„Was ist eine abstrakte Klasse?" → Klasse die nicht direkt instanziiert werden kann, kann abstrakte Methoden enthalten
„Was ist ein Interface?" → reine Methoden-Vertrag ohne Zustand, kann von vielen Klassen implementiert werden
„Unterschied zwischen abstract und interface?" → Tabelle aus Abschnitt 4 erinnern: Zustand, Konstruktor, Mehrfach-Implementation
„Wann nimmst du was?" → abstract bei is-a + gemeinsamem Code; interface bei „can do"-Fähigkeit oder Mehrfach
„Warum hat Java Interfaces wenn es schon abstract gibt?" → Mehrfach-Implementierung; vermeidet Diamond-Problem
„Was ist eine Default-Methode?" → Java 8+ Feature: Interface-Methode mit Implementierung; erlaubt Erweiterung bestehender Interfaces
„Was ist ein Marker-Interface?" → leeres Interface zur Typ-Markierung, z.B. Serializable
„Kann ein Interface von einem anderen Interface erben?" → ja, mit extends; ein Interface kann sogar mehrere andere erweitern

Zusammenfassung

Abstrakte Klasse: nicht instanziierbar, kann abstrakte + konkrete Methoden + Felder + Konstruktor haben. Für is-a-Hierarchien mit gemeinsamem Code. Interface: reiner Vertrag, nur Methodensignaturen, keine Felder (außer Konstanten), keinen Konstruktor. Eine Klasse extends max. eine Klasse, implements viele Interfaces. Java 8+ bringt Default-Methoden in Interfaces – Implementierung erlaubt, aber kein Zustand. Faustregel: abstrakte Klasse für gemeinsame Implementierung, Interface für Capability-Verträge. Python nutzt ABC oder Protocol, TypeScript hat strukturelle Interfaces. Bewerbungs-Klassiker: „Unterschied zwischen abstract und interface" – beherrschen!