Objektorientierte Programmierung in Java: Klassen, Interfaces und gutes Design

Von Guido Zeuner · Softwareentwickler und Autor von tiny-tool.de

Objektorientierung ist mehr als Klassen, Vererbung und Getter. Sie hilft dir, fachliche Regeln in klar abgegrenzten Typen abzubilden, Zustände zu schützen und austauschbare Komponenten über stabile Verträge zusammenarbeiten zu lassen.

In Java modellierst du Objekte mit Zustand und Verhalten. Gutes objektorientiertes Design beginnt jedoch nicht mit möglichst vielen Klassen, sondern mit einer einfachen Frage: Welche Verantwortung gehört wohin? Dieser Guide führt von Klassen und Objekten über Kapselung, Interfaces und Polymorphie bis zu Komposition, Records und Sealed Types – mit praxisnahen Beispielen und einem kompakten Kotlin-Vergleich.

Was objektorientierte Programmierung wirklich bedeutet

Ein Objekt bündelt zusammengehörigen Zustand und das dazu passende Verhalten. Statt Daten durch viele unverbundene Funktionen zu reichen, erhält ein Typ die Verantwortung für seine eigenen Regeln. Ein Konto kennt beispielsweise seinen Kontostand und entscheidet selbst, ob eine Auszahlung zulässig ist.

Die bekannte Einteilung in Kapselung, Abstraktion, Vererbung und Polymorphie ist als Einstieg nützlich. Sie ist aber keine Checkliste, nach der jede Anwendung möglichst viel Vererbung oder besonders viele Abstraktionen enthalten sollte. Entscheidend ist, ob das Modell verständlich bleibt und ungültige Zustände erschwert.

Objektorientierter Code ist nicht automatisch guter Code. Eine Klasse mit zwanzig öffentlichen Settern kapselt ihre Daten technisch, schützt aber kaum fachliche Regeln.

Klassen und Objekte: Bauplan und konkrete Instanz

Eine Klasse deklariert Felder, Konstruktoren und Methoden. Mit new entsteht daraus ein Objekt. Jede Instanz besitzt ihren eigenen Zustand, während der Code der Methoden durch die Klasse festgelegt wird.

import java.math.BigDecimal;
import java.util.Objects;

public final class BankAccount {
    private final String iban;
    private BigDecimal balance;

    public BankAccount(String iban, BigDecimal openingBalance) {
        this.iban = Objects.requireNonNull(iban, "iban");
        this.balance = requireNonNegative(openingBalance);
    }

    public String iban() {
        return iban;
    }

    public BigDecimal balance() {
        return balance;
    }

    public void deposit(BigDecimal amount) {
        balance = balance.add(requirePositive(amount));
    }

    public void withdraw(BigDecimal amount) {
        BigDecimal checkedAmount = requirePositive(amount);

        if (balance.compareTo(checkedAmount) < 0) {
            throw new IllegalStateException("Kontostand reicht nicht aus");
        }

        balance = balance.subtract(checkedAmount);
    }

    private static BigDecimal requirePositive(BigDecimal amount) {
        Objects.requireNonNull(amount, "amount");
        if (amount.signum() <= 0) {
            throw new IllegalArgumentException("Betrag muss positiv sein");
        }
        return amount;
    }

    private static BigDecimal requireNonNegative(BigDecimal amount) {
        Objects.requireNonNull(amount, "openingBalance");
        if (amount.signum() < 0) {
            throw new IllegalArgumentException("Startguthaben darf nicht negativ sein");
        }
        return amount;
    }
}

Die Klasse ist bewusst final: Ohne konkreten Erweiterungspunkt gibt es keinen Grund, beliebige Unterklassen zuzulassen. Die IBAN wird nach dem Erzeugen nicht mehr ausgetauscht, der Kontostand darf sich dagegen über kontrollierte Methoden verändern.

BankAccount checking = new BankAccount(
        "DE02120300000000202051", new BigDecimal("250.00"));
BankAccount savings = new BankAccount(
        "DE02120300000000202052", new BigDecimal("1000.00"));

checking.withdraw(new BigDecimal("49.90"));
savings.deposit(new BigDecimal("100.00"));

checking und savings verweisen auf unterschiedliche Instanzen. Eine Änderung am einen Konto verändert das andere nicht. Die Variablen enthalten Referenzen auf die Objekte – nicht die Objekte selbst.

Kapselung: gültige Zustände statt Setter-Sammlung

Die stärkste Eigenschaft von BankAccount ist nicht das Schlüsselwort private, sondern die Kontrolle über Zustandsänderungen. Es gibt keinen setBalance(...)-Aufruf, der den Kontostand ohne Prüfung auf einen beliebigen Wert setzt. Stattdessen drücken deposit(...) und withdraw(...) fachliche Absichten aus.

Eine Regel, die für jedes gültige Objekt gelten muss, heißt Invariante. Im Beispiel sind Einzahlungen positiv, das Startguthaben ist nicht negativ und eine Auszahlung kann das Konto nicht unter null drücken. Konstruktor und Methoden bewahren diese Regeln gemeinsam.

Wähle die kleinste sinnvolle Sichtbarkeit. Was heute öffentlich ist, wird schnell zu einem Vertrag, den anderer Code erwartet und den du später nur schwer ändern kannst.

Interfaces und Polymorphie: gegen Verträge programmieren

Ein Interface beschreibt, was ein Typ anbietet, ohne eine bestimmte Implementierung vorzuschreiben. Unabhängige Klassen können dasselbe Interface implementieren. Eine Variable des Interface-Typs kann anschließend auf jede passende Implementierung verweisen.

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.Objects;

public interface DiscountPolicy {
    BigDecimal applyTo(BigDecimal subtotal);
}

final class NoDiscount implements DiscountPolicy {
    @Override
    public BigDecimal applyTo(BigDecimal subtotal) {
        return requireNonNegative(subtotal);
    }

    private static BigDecimal requireNonNegative(BigDecimal value) {
        Objects.requireNonNull(value, "subtotal");
        if (value.signum() < 0) {
            throw new IllegalArgumentException("Zwischensumme darf nicht negativ sein");
        }
        return value;
    }
}

final class PercentageDiscount implements DiscountPolicy {
    private final BigDecimal rate;

    public PercentageDiscount(BigDecimal rate) {
        Objects.requireNonNull(rate, "rate");
        if (rate.signum() < 0 || rate.compareTo(BigDecimal.ONE) > 0) {
            throw new IllegalArgumentException("Rabatt muss zwischen 0 und 1 liegen");
        }
        this.rate = rate;
    }

    @Override
    public BigDecimal applyTo(BigDecimal subtotal) {
        Objects.requireNonNull(subtotal, "subtotal");
        if (subtotal.signum() < 0) {
            throw new IllegalArgumentException("Zwischensumme darf nicht negativ sein");
        }

        return subtotal.multiply(BigDecimal.ONE.subtract(rate))
                .setScale(2, RoundingMode.HALF_UP);
    }
}

Aufrufender Code muss nicht wissen, welche konkrete Rabattregel aktiv ist. Die Auswahl kann beim Start, anhand einer Konfiguration oder durch Dependency Injection erfolgen:

DiscountPolicy policy = new PercentageDiscount(new BigDecimal("0.10"));
BigDecimal total = policy.applyTo(new BigDecimal("89.90"));

System.out.println(total); // 80.91

Welche Methode ausgeführt wird, entscheidet Java zur Laufzeit anhand des tatsächlichen Objekts. Das ist dynamische Polymorphie. Neue Implementierungen lassen sich ergänzen, ohne den verwendenden Code mit einer wachsenden if– oder switch-Kette zu belasten.

Vererbung oder Komposition?

Java erlaubt einer Klasse genau eine direkte Oberklasse, aber mehrere implementierte Interfaces. Vererbung kann gemeinsamen Code und einen gemeinsamen Typ bereitstellen. Gleichzeitig koppelt sie eine Unterklasse eng an Aufbau und Verhalten ihrer Oberklasse.

Prüfe deshalb zuerst die Beziehung:

• Ist-ein: Ein Circle ist eine Shape und kann überall verwendet werden, wo eine Shape erwartet wird.
• Hat-ein: Ein CheckoutService hat eine DiscountPolicy. Er ist keine Rabattregel.

Die Preisregel aus dem vorherigen Abschnitt lässt sich per Komposition in einen Service einsetzen:

import java.math.BigDecimal;
import java.util.Objects;

public final class CheckoutService {
    private final DiscountPolicy discountPolicy;

    public CheckoutService(DiscountPolicy discountPolicy) {
        this.discountPolicy = Objects.requireNonNull(
                discountPolicy, "discountPolicy");
    }

    public BigDecimal calculateTotal(BigDecimal subtotal) {
        return discountPolicy.applyTo(subtotal);
    }
}

Der Service ist nicht an PercentageDiscount gebunden, sondern nur an den kleinen Vertrag DiscountPolicy. In einem Test kannst du eine einfache Testimplementierung einsetzen. Im Produktivbetrieb kann eine andere Regel verwendet werden, ohne CheckoutService zu verändern.

abstract, final und sealed: Erweiterbarkeit ausdrücken

Eine API sollte nicht zufällig erweiterbar sein. Java bietet mehrere Möglichkeiten, die beabsichtigte Form einer Hierarchie sichtbar zu machen:

Sealed Types sind besonders nützlich, wenn alle zulässigen Varianten bekannt sind. Ein switch kann dadurch vollständig und ohne pauschalen default-Zweig formuliert werden:

public sealed interface PaymentResult permits Approved, Rejected {}

record Approved(String transactionId) implements PaymentResult {}

record Rejected(String reason) implements PaymentResult {}

final class PaymentMessages {
    private PaymentMessages() {}

    static String messageFor(PaymentResult result) {
        return switch (result) {
            case Approved approved ->
                    "Zahlung bestätigt: " + approved.transactionId();
            case Rejected rejected ->
                    "Zahlung abgelehnt: " + rejected.reason();
        };
    }
}

Fügst du später eine weitere erlaubte Variante hinzu, weist der Compiler auf nicht mehr vollständige switch-Ausdrücke hin. Das ist ein Vorteil gegenüber einer offenen Hierarchie, in der zur Laufzeit unerwartete Untertypen auftreten können.

Records: kompakte Datenträger und Wertobjekte

Records eignen sich für Daten, deren Bedeutung hauptsächlich durch ihre Komponenten bestimmt wird. Der Compiler erzeugt unter anderem Zugriffsmethoden, equals(), hashCode() und toString(). Records sind implizit final.

import java.math.BigDecimal;
import java.util.Currency;
import java.util.Objects;

public record Price(BigDecimal amount, Currency currency) {
    public Price {
        Objects.requireNonNull(amount, "amount");
        Objects.requireNonNull(currency, "currency");

        if (amount.signum() < 0) {
            throw new IllegalArgumentException("Preis darf nicht negativ sein");
        }
    }

    public Price add(Price other) {
        Objects.requireNonNull(other, "other");
        if (!currency.equals(other.currency)) {
            throw new IllegalArgumentException("Währungen stimmen nicht überein");
        }
        return new Price(amount.add(other.amount), currency);
    }
}

Ein Record ist nicht automatisch tief unveränderlich. Seine Komponenten können nach der Konstruktion nicht neu zugewiesen werden, doch ein darin referenziertes veränderliches Objekt kann weiterhin verändert werden. BigDecimal und Currency sind für dieses Beispiel geeignete unveränderliche Bausteine.

Identität und Gleichheit: ==, equals() und hashCode()

Bei Referenztypen prüft ==, ob zwei Variablen auf dasselbe Objekt verweisen. equals() beantwortet dagegen die fachliche Frage, ob zwei Objekte als gleich gelten. Die von Object geerbte Standardimplementierung verwendet ebenfalls Identität, solange eine Klasse sie nicht überschreibt.

Currency eur = Currency.getInstance("EUR");

Price first = new Price(new BigDecimal("19.90"), eur);
Price second = new Price(new BigDecimal("19.90"), eur);

System.out.println(first == second);      // false
System.out.println(first.equals(second)); // true

Überschreibst du equals() in einer normalen Klasse, musst du dazu ein konsistentes hashCode() bereitstellen. Das ist besonders für HashMap und HashSet wichtig. Records erzeugen beide Methoden komponentenbasiert und gemeinsam.

Java und Kotlin: Objektorientierung auf derselben JVM

Java und Kotlin arbeiten auf der JVM problemlos zusammen und teilen viele objektorientierte Grundlagen. Kotlin setzt jedoch andere Standardeinstellungen und bietet kompaktere Sprachmittel. Das verändert nicht das Ziel guten Designs, wohl aber dessen Schreibweise.

Das Java-Record-Beispiel lässt sich in Kotlin als Data Class ausdrücken:

import java.math.BigDecimal
import java.util.Currency

data class Price(
    val amount: BigDecimal,
    val currency: Currency
) {
    init {
        require(amount.signum() >= 0) {
            "Preis darf nicht negativ sein"
        }
    }

    operator fun plus(other: Price): Price {
        require(currency == other.currency) {
            "Währungen stimmen nicht überein"
        }
        return copy(amount = amount + other.amount)
    }
}

val verhindert, dass die Property auf einen anderen Wert gesetzt wird. Wie bei Java bedeutet das keine automatische tiefe Unveränderlichkeit: Ein mit val referenziertes veränderliches Objekt kann weiterhin seinen internen Zustand ändern.

Data Classes und Records sind verwandt, aber nicht identisch. Eine Kotlin Data Class kann beispielsweise Properties mit var besitzen und erzeugt copy(). Ein Java Record hat eine fest definierte Record-Struktur und kann von Kotlin über seine Komponenten verwendet werden; Kotlin unterstützt umgekehrt auf der JVM auch die Deklaration echter Java Records mit @JvmRecord.

Best Practices und typische Anti-Patterns

1. Tell, don’t ask – aber ohne Dogma

Statt den Zustand eines Objekts auszulesen, extern zu verändern und zurückzuschreiben, rufst du besser eine fachliche Operation auf. account.withdraw(amount) lässt das Konto seine Regeln selbst schützen. Reine Abfragen bleiben selbstverständlich sinnvoll, wenn anderer Code Informationen tatsächlich anzeigen oder auswerten muss.

2. Kleine Verträge statt vorsorglicher Abstraktionen

Ein Interface ist wertvoll, wenn mehrere Implementierungen existieren, eine Systemgrenze entkoppelt oder eine Rolle ausdrücklich beschrieben werden soll. Ein Interface nur für eine triviale Klasse anzulegen, macht das Modell nicht automatisch flexibler.

3. Untertypen müssen den Vertrag erfüllen

Wenn Code einen Obertyp erwartet, muss jede Unterklasse dessen Zusagen einhalten. Eine Unterklasse, die erlaubte Eingaben plötzlich ablehnt oder nach einer geerbten Methode in einem unerwarteten Zustand endet, ist kein sauberer Ersatz. Das ist der praktische Kern des Liskovschen Substitutionsprinzips.

4. Unveränderlichkeit reduziert Zustandsfehler

Unveränderliche Objekte sind leichter zu teilen, zu testen und nachzuvollziehen. Nutze final-Felder und Records, wenn Änderungen nicht zur Identität des Konzepts gehören. Veränderlicher Zustand ist nicht grundsätzlich falsch – er sollte nur eng gekapselt und über klare Operationen verändert werden.