FAQ Page: solid-prinzipien

Ja, z. B. bei kleinen, kurzlebigen Projekten oder MVPs, wo Overengineering mehr schadet als hilft. Auch bei stark performancekritischem Code kann man SRP oder DIP bewusst lockern – solange man das technische Risiko bewusst managt.

Dann sind Clients gezwungen, Methoden zu implementieren, die sie gar nicht brauchen – was zu unnötiger Komplexität, Dummy-Implementierungen oder eng gekoppelten Klassen führt.Beispiel: Ein IMultiFunctionDevice-Interface mit Print, Scan, Fax zwingt einfache Geräte wie einen Scanner zur Implementierung nicht benötigter Methoden.

Wenn eine abgeleitete Klasse das Verhalten oder die Erwartungen der Basisklasse verändert (z. B. durch das Werfen unerwarteter Exceptions oder das Ignorieren von Basisverträgen), wird LSP verletzt.Ein klassisches Beispiel: Eine Square-Klasse, die von Rectangle erbt, aber bei setWidth auch die Höhe verändert – das verletzt das Verhalten der Basisklasse.

Das OCP besagt, dass eine Softwarekomponente offen für Erweiterung, aber geschlossen für Modifikation sein soll. Das heißt: Neue Funktionalität kann durch Erweiterung (z. B. über Vererbung oder Komposition) hinzugefügt werden, ohne bestehenden Code zu verändern.Beispiel: Statt eine PaymentProcessor-Klasse direkt zu ändern, kann man neue Zahlungsmethoden über Subklassen oder Strategien einfügen.

Wenn eine Klasse mehr als einen Grund zur Änderung hat – also mehrere Verantwortlichkeiten trägt (z. B. Datenverarbeitung und Logging oder UI-Logik und Datenhaltung) – verstößt sie gegen SRP. Typische Anzeichen sind zu viele Methoden mit unterschiedlichen thematischen Zwecken oder häufige Änderungen aus verschiedenen Gründen.

SOLID ist ein Akronym für fünf Prinzipien objektorientierten Designs, die helfen, Software robuster, wartbarer und erweiterbarer zu gestalten: