Modul 1: SOLID Principles — Fünf Regeln für wartbaren Code

Warum SOLID?

SOLID sind fünf Design-Prinzipien, die Klassen und Module so strukturieren, dass Änderungen lokal bleiben und Tests einfach sind. Sie sind kein Gesetz, sondern Heuristiken — je größer das Team und je länger das System lebt, desto wichtiger werden sie.

Lesson 1: Single Responsibility Principle (SRP)

Eine Klasse sollte genau einen Grund zur Änderung haben. Eine ReportGenerator-Klasse, die Daten lädt, formatiert und per E-Mail versendet, hat drei Gründe zur Änderung: Datenquelle, Format, Versand. Extrahiere drei Klassen — jede mit einer Verantwortung.

// Schlimm: drei Verantwortungen
class ReportService {
    void generate() { /* lädt, formatiert, versendet */ }
}

// Besser: eine Verantwortung pro Klasse
class ReportRepository { Data load() { ... } }
class ReportFormatter  { String format(Data d) { ... } }
class ReportSender     { void send(String s) { ... } }

Lesson 2: Open/Closed Principle (OCP)

Klassen sollten offen für Erweiterung, geschlossen für Modifikation sein. Statt einen DiscountCalculator mit if (customer == VIP) ... else if (...) zu erweitern, definiere ein DiscountStrategy-Interface. Neue Rabatttypen kommen als neue Klassen — bestehender Code bleibt unangetastet.

Lesson 3: Liskov Substitution Principle (LSP)

Subtypen müssen überall dort einsetzbar sein, wo der Basistyp erwartet wird, ohne das Verhalten zu brechen. Das klassische Gegenbeispiel: Square extends Rectangle — wer setWidth(4); setHeight(5) auf ein Quadrat anwendet, erwartet eine Fläche von 20, erhält aber 25. Vererbung bricht hier; Komposition oder ein gemeinsames Interface löst das Problem.

Lesson 4: Interface Segregation Principle (ISP)

Viele kleine Interfaces schlagen ein fettes Universal-Interface. Ein MultiFunctionDevice mit print(), scan() und fax() zwingt jede Implementierung, alle drei Methoden anzubieten — auch einen reinen Drucker. Segregiere in Printer, Scanner und Fax, und kombiniere sie bei Bedarf.

Lesson 5: Dependency Inversion Principle (DIP)

High-Level-Module (Geschäftslogik) sollten nicht von Low-Level-Modulen (DB, HTTP) abhängen — beide hängen von Abstraktionen ab. Ein OrderService kennt ein OrderRepository-Interface, nicht die konkrete JpaOrderRepository. So kann man im Test ein InMemoryOrderRepository injizieren.