SOLID — die fünf Prinzipien
S — Single Responsibility:
Eine Klasse hat genau einen Grund, sich zu ändern. Eine Klasse UserReport sollte sich nur ändern, wenn das Report‑Format ändert — nicht wegen Datenbank‑Schema.
O — Open/Closed:
Offen für Erweiterung, geschlossen für Modifikation. Neuen Bezahl‑Provider hinzufügen → neue Klasse, nicht alte ändern.
L — Liskov Substitution:
Subtypen müssen dort funktionieren, wo der Basistyp erwartet wird. Square extends Rectangle bricht oft, weil ein Quadrat nicht alle Rectangle‑Verträge erfüllt.
I — Interface Segregation:
Lieber viele kleine, spezifische Interfaces als wenige große. Niemand sollte Methoden implementieren müssen, die er nicht braucht.
D — Dependency Inversion:
High‑Level Module sollten nicht von Low‑Level Modulen abhängen, sondern beide von Abstraktionen. OrderService hängt von PaymentGateway Interface, nicht von StripeClient.
Zurück zu Informatik