SOLID sind fünf Designprinzipien zum Aufbau wartbarer, flexibler OOP-Systeme. Jedes behandelt eine häufige Ursache für starren, fragilen Code.
SOLID sind fünf Designprinzipien zum Aufbau wartbarer, flexibler OOP-Systeme. Jedes behandelt eine häufige Ursache für starren, fragilen Code.
| Buchstabe | Prinzip | Einzeilige Bedeutung |
|---|
| S | Single Responsibility | Eine Klasse sollte einen Grund zur Änderung haben |
| O | Open/Closed | Offen für Erweiterung, geschlossen für Änderung |
| L | Liskov Substitution | Untertypen müssen überall verwendbar sein, wo der Basistyp verwendet wird |
| I | Interface Segregation | Viele kleine Schnittstellen schlagen eine große |
| D | Dependency Inversion | Abhängig von Abstraktionen, nicht von konkreten Klassen |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService ist nicht spezifisch von E-Mail abhängig – wechseln Sie zu SMS oder einen Test Double, ohne es zu berühren (D). Das Hinzufügen eines neuen Notifier-Typs erfordert keine Änderung an OrderService (O).
SOLID ist Anleitung, kein Gesetz. Überanwendung – eine Schnittstelle pro Klasse, Indirektion überall – erzeugt "Abstraktionssuppe", die schwerer zu verfolgen ist als das Problem, das sie gelöst hat.
SOLID bietet eine gemeinsame diagnostische Sprache: Reviewer können benennen, warum eine Klasse schwer zu ändern ist ("dies verletzt SRP"), statt nach Geschmack zu argumentieren.
Wenn es mit Urteilsvermögen angewendet wird, verringern die Prinzipien Ripple-Effekte – Änderungen bleiben lokal, neue Funktionen erweitern statt zu überschreiben, und Tests können Fakes für echte Abhängigkeiten ersetzen.