Zu viel Verantwortung im Code? Zeit für das Single Responsibility Principle

Wenn du dich noch nicht lange mit objektorientierter Programmierung beschäftigst, stolperst du relativ früh über die sogenannten SOLID-Prinzipien. Eines davon ist das SRP - das Single Responsibility Principle. Klingt erstmal theoretisch, ist in der Praxis aber eines der Prinzipien, die dir den grössten Hebel bringen, wenn dein Code wartbar bleiben soll.

Was bedeutet SRP eigentlich?

Das Single Responsibility Principle besagt: Eine Klasse soll genau eine Verantwortung haben. Nicht zwei. Nicht „hauptsächlich eine“. Sondern genau eine.

Wichtig dabei: Verantwortung meint keinen einzelnen Methodennamen oder Task, sondern einen fachlichen Grund, warum sich die Klasse ändert. Wenn es mehrere unterschiedliche Gründe gibt, aus denen du die Klasse anpassen müsstest, hast du SRP verletzt.

Das klingt abstrakt, wird aber schnell greifbar, wenn man sich Code anschaut.

Ein typisches Beispiel aus dem Alltag

Stell dir eine Klasse vor, die einen Benutzer speichert, validiert und gleichzeitig in eine Datei schreibt. Für Anfänger wirkt das erstmal logisch: alles, was mit Benutzer zu tun hat, kommt eben in eine Klasse.

public class UserService {

    public void register(User user) {
        validate(user);
        saveToDatabase(user);
        writeLogFile(user);
    }

    private void validate(User user) {
        // Validierungslogik
    }

    private void saveToDatabase(User user) {
        // Persistenzlogik
    }

    private void writeLogFile(User user) {
        // Datei-Logging
    }
}

Auf den ersten Blick funktioniert das. Das Problem zeigt sich erst später. Änderungen an der Validierung, am Logging oder an der Art, wie gespeichert wird, treffen immer dieselbe Klasse. Sie hat also mehrere Gründe, sich zu ändern. Genau das widerspricht SRP.

Warum ist das ein echtes Problem?

Solche Klassen werden mit der Zeit immer grösser. Tests werden komplizierter, weil du beim Testen der Validierung automatisch auch den Rest mit im Boot hast. Kleine Änderungen ziehen unerwartete Nebenwirkungen nach sich. Und irgendwann traut sich niemand mehr ran, „nur kurz“ etwas anzupassen.

SRP sorgt nicht dafür, dass dein Code akademisch schön aussieht, sondern dass du ihn auch nach ein paar Monaten noch entspannt lesen und verstehen kannst.

Ein SRP-konformer Ansatz

Die Idee ist simpel: Jede Klasse bekommt einen klaren Zweck. Validierung ist eine Verantwortung. Persistenz ist eine andere. Logging wieder eine eigene.

public class UserService {

    private final UserValidator validator;
    private final UserRepository repository;
    private final UserLogger logger;

    public UserService(UserValidator validator, UserRepository repository, UserLogger logger) {
        this.validator = validator;
        this.repository = repository;
        this.logger = logger;
    }

    public void register(User user) {
        validator.validate(user);
        repository.save(user);
        logger.log(user);
    }
}

Jetzt hat der UserService genau eine Verantwortung: den Ablauf der Benutzerregistrierung zu koordinieren. Ändert sich die Validierungslogik, fasst du den Validator an. Ändert sich die Art der Speicherung, betrifft das nur das Repository. Jede Klasse hat einen klaren Grund, sich zu ändern.

SRP heisst nicht: eine Methode pro Klasse

Ein häufiges Missverständnis ist, dass SRP bedeuten würde, Klassen müssen winzig sein oder dürfen nur eine Methode enthalten. Das ist Unsinn. Eine Klasse darf viele Methoden haben, solange sie alle derselben fachlichen Verantwortung dienen.

Eine UserValidator-Klasse kann problemlos mehrere Validierungsregeln enthalten. Entscheidend ist nicht die Anzahl der Methoden, sondern der gedankliche Zusammenhang.

Wie erkennst du SRP-Verletzungen?

Eine einfache Frage hilft oft weiter: „Warum würde ich diese Klasse ändern?“ Wenn dir mehrere unterschiedliche Antworten einfallen, ist das ein ziemlich klares Signal.

Weitere Warnzeichen sind Klassen, die Daten speichern und gleichzeitig darstellen, oder Fachlogik enthalten und zusätzlich technische Details wie Dateizugriffe oder HTTP-Aufrufe regeln.

Bezug zu JavaEE und dem echten Projektalltag

Gerade in JavaEE-Anwendungen sieht man SRP-Verletzungen häufig in Service-Klassen, die Geschäftslogik, Datenbankzugriffe, Validierung und Logging vermischen. Frameworks wie JPA, CDI oder Bean Validation machen es dir aber leicht, diese Verantwortungen sauber zu trennen.

Wenn deine Services schlank bleiben und sich auf Ablauf und Fachlogik konzentrieren, wird der Rest automatisch strukturierter. Tests werden einfacher, Klassen kleiner und Änderungen risikoärmer.

Fazit

Das Single Responsibility Principle ist kein theoretisches Regelwerk für Perfektionisten. Es ist ein extrem praktisches Werkzeug, um Code langfristig beherrschbar zu halten. Gerade am Anfang lohnt es sich, bewusst darauf zu achten.

Wenn du nicht sicher bist, ob dein Code SRP erfüllt, ist das normal. Das Gefühl dafür entwickelt sich mit der Zeit. Wichtig ist nur, dass du anfängst, die richtigen Fragen zu stellen. Der Rest kommt von selbst.