SOLID-Prinzipien in Java: Theorie und Praxis für sauberen Code

Einführung: Warum SOLID für Java-Entwickler wichtig ist

In der Welt der objektorientierten Programmierung werden Wartung und Erweiterung von Code mit der Zeit immer komplexer. Ohne eine klare Architektur verwandelt sich selbst ein kleines Projekt in einen "großen Schlamassel", bei dem die Änderung einer Funktion zehn andere zerstört. Hier kommen die SOLID-Prinzipien ins Spiel – fünf grundlegende Regeln für das Klassendesign, formuliert von Robert C. Martin (Uncle Bob).

Für einen Java-Entwickler ist SOLID nicht nur Theorie, sondern ein praktisches Werkzeug. Java, als stark typisierte Sprache mit einem leistungsfähigen System von Interfaces und Vererbung, eignet sich ideal für die Umsetzung dieser Prinzipien. In diesem Artikel werden wir jedes Prinzip aus theoretischer Sicht betrachten und praktische Java-Codebeispiele zeigen, die Sie sofort in Ihrem Projekt anwenden können.

1. Single Responsibility Principle (Prinzip der einzigen Verantwortung)

Theorie

SRP besagt: Eine Klasse sollte nur einen einzigen Grund für eine Änderung haben. Mit anderen Worten, eine Klasse sollte für eine klar definierte Funktionalität verantwortlich sein. Wenn eine Klasse zu viel tut, wird sie schwer zu testen, zu ändern und wiederzuverwenden.

Praxis in Java

Betrachten wir eine typische SRP-Verletzung – eine Klasse, die gleichzeitig Benutzerdaten verwaltet und Benachrichtigungen sendet:

// ❌ Verletzung des SRPpublic class User {    private String name;    private String email;

    public void saveToDatabase() {        // Speichern in der DB    }

    public void sendWelcomeEmail() {        // E-Mail senden    }}

Die richtige Lösung ist, die Verantwortung auf zwei Klassen aufzuteilen:

// ✅ Einhaltung des SRPpublic class User {    private String name;    private String email;    // Getter und Setter}

public class UserRepository {    public void save(User user) {        // Speichern in der DB    }}

public class EmailService {    public void sendWelcomeEmail(User user) {        // E-Mail senden    }}

Fazit: Jede Klasse hat jetzt nur einen Grund für eine Änderung. User ändert sich nur bei Änderungen der Datenstruktur, UserRepository bei Änderungen der DB-Logik, EmailService bei Änderungen der E-Mail-Vorlagen.

2. Open-Closed Principle (Prinzip der Offenheit/Geschlossenheit)

Theorie

OCP besagt: Klassen sollten offen für Erweiterungen, aber geschlossen für Modifikationen sein. Das bedeutet, dass neue Funktionalität durch Vererbung oder Komposition hinzugefügt werden sollte, ohne den bereits getesteten Code zu verändern.

Praxis in Java

Stellen Sie sich vor, Sie haben einen Rabattrechner für verschiedene Kundentypen:

// ❌ Verletzung des OCPpublic class DiscountCalculator {    public double calculateDiscount(String customerType, double amount) {        if (customerType.equals(\"Regular\")) {            return amount * 0.1;        } else if (customerType.equals(\"Premium\")) {            return amount * 0.2;        }        return 0;    }}

Beim Hinzufügen eines neuen Kundentyps (z.B. "Gold") müsste die bestehende Klasse geändert werden. Die Lösung ist die Verwendung von Polymorphismus:

// ✅ Einhaltung des OCPpublic interface DiscountStrategy {    double calculate(double amount);}

public class RegularDiscount implements DiscountStrategy {    @Override    public double calculate(double amount) {        return amount * 0.1;    }}

public class PremiumDiscount implements DiscountStrategy {    @Override    public double calculate(double amount) {        return amount * 0.2;    }}

public class DiscountCalculator {    private DiscountStrategy strategy;

    public DiscountCalculator(DiscountStrategy strategy) {        this.strategy = strategy;    }

    public double calculate(double amount) {