SOLID-Prinzipien
SOLID ist ein Akronym für fünf Design-Prinzipien, die in den frühen 2000ern von Robert C. Martin („Uncle Bob") zusammengefasst wurden. Sie beantworten die Frage: wie schreibe ich OOP-Code, der sauber, wartbar und erweiterbar bleibt? Wer sie kennt und anwendet, hebt sich von Junior-Entwicklern deutlich ab.
Diese Lektion ist klausurkritisch. SOLID kommt in IHK-Abschlussprüfungen, in Software-Engineering-Modulen und in jedem Vorstellungsgespräch. Wir gehen jedes Prinzip einzeln durch, zeigen den klassischen Verstoß und die saubere Lösung. Am Ende eine Checkliste für eigenen Code.
1) Was SOLID bedeutet
Jeder Buchstabe steht für ein Prinzip. Klick die Buchstaben an für eine Kurzdefinition:
Die fünf Buchstaben von SOLID
S
Single Responsibility
Eine Verantwortung
O
Open/Closed
Offen für Erweiterung
L
Liskov Substitution
Sub ersetzt Super
I
Interface Segregation
Kleine Interfaces
D
Dependency Inversion
Abhängigkeiten umdrehen
Wichtig: SOLID sind Richtlinien, keine Gesetze. Sie helfen großen Code-Basen sauber zu bleiben. In Mini-Skripten sind sie oft Overhead. Wie alle Best Practices: kontextabhängig anwenden.
2) S – Single Responsibility Principle (SRP)
SRP – das Prinzip der einen Verantwortung
S
Single Responsibility Principle
„Eine Klasse sollte nur einen einzigen Grund haben sich zu ändern."
Jede Klasse sollte genau eine klar umrissene Aufgabe haben. Wenn du eine Klasse mit „und" beschreiben musst („verwaltet Kunden UND schreibt Rechnungen UND sendet E-Mails"), ist das ein Warnsignal.
Verstoß
Eine Klasse macht alles auf einmal:
class Mitarbeiter:
def get_name(self): ...
def berechne_gehalt(self): ...
def speichere_in_db(self): ...
def sende_email(self): ...
def generiere_pdf(self): ...
# 5 verschiedene Verantwortungen!
Sauber
Jede Klasse hat genau eine Aufgabe:
class Mitarbeiter: # nur Daten
def get_name(self): ...
class GehaltRechner: # nur Berechnung
def berechne(self, m): ...
class MitarbeiterRepo: # nur DB
def speichere(self, m): ...
class EmailService: # nur E-Mail
def sende(self, m, msg): ...
Warum? Wenn sich die Steuerregeln ändern, willst du nur den GehaltRechner anfassen – nicht die ganze Mitarbeiter-Klasse mit allen anderen Methoden. Auch beim Testen ist's einfacher: du testest die Berechnung isoliert ohne die DB anzustarten.
3) O – Open/Closed Principle (OCP)
OCP – offen für Erweiterung, geschlossen für Änderung
O
Open/Closed Principle
„Software-Bausteine sollen offen für Erweiterung, aber geschlossen für Modifikation sein."
Neue Funktionalität durch neuen Code, nicht durch Ändern von bestehendem. Verwende Vererbung, Polymorphismus oder Interfaces.
Verstoß
if-elif-Block der bei jedem neuen Typ wächst:
def berechne_flaeche(form):
if form.typ == "kreis":
return 3.14 * form.r ** 2
elif form.typ == "rechteck":
return form.b * form.h
elif form.typ == "dreieck":
return 0.5 * form.b * form.h
# ...neue Form? Funktion ändern!
Sauber
Polymorphismus – neue Klasse hinzu, nichts ändern:
class Form(ABC):
@abstractmethod
def flaeche(self): pass
class Kreis(Form):
def flaeche(self):
return 3.14 * self.r ** 2
class Rechteck(Form):
def flaeche(self):
return self.b * self.h
# Neue Form? Einfach neue Klasse!
Das ist genau der Polymorphismus aus L6 – statt if-else-Ketten lassen die Klassen sich selbst verarbeiten. Wenn morgen ein „Trapez" kommt, schreibst du eine neue Klasse ohne die bestehende Code-Basis anzufassen.
4) L – Liskov Substitution Principle (LSP)
LSP – Unterklassen müssen ersetzbar sein
L
Liskov Substitution Principle
„Subtypen müssen für ihre Basistypen substituierbar sein, ohne dass das Programm bricht."
Benannt nach Barbara Liskov. Wenn dein Code
Form erwartet, sollte er mit jedem Subtyp (Kreis, Rechteck, …) funktionieren – ohne Spezialbehandlung. Verstoß
Pinguin „ist ein" Vogel, kann aber nicht fliegen:
class Vogel:
def fliegen(self):
print("Fliege!")
class Pinguin(Vogel):
def fliegen(self):
raise Exception("kann nicht!")
# Code der mit Vogel arbeitet,
# crasht bei Pinguin → LSP verletzt
Sauber
Hierarchie neu denken:
class Vogel: pass
class FliegenderVogel(Vogel):
def fliegen(self):
print("Fliege!")
class Pinguin(Vogel):
def schwimmen(self):
print("Schwimme!")
# Code erwartet jetzt
# FliegenderVogel - kein Pinguin
# kann reingegeben werden
LSP wurde schon in L6 angesprochen. Klassiker-Verstoß: Quadrat erbt von Rechteck. Funktioniert auf den ersten Blick (Quadrat IST ein spezielles Rechteck), aber sobald du
setBreite() und setHoehe() hast, geht's schief – beim Quadrat müsste beides gleichzeitig gesetzt werden. Vererbung lügt.5) I – Interface Segregation Principle (ISP)
ISP – lieber viele kleine Interfaces als ein großes
I
Interface Segregation Principle
„Klienten sollen nicht gezwungen werden, von Interfaces abzuhängen, die sie nicht nutzen."
Statt einem riesigen
AlleMaschinen-Interface mit 50 Methoden lieber mehrere kleine: Druckbar, Scannbar, Faxbar. Klassen implementieren nur was sie wirklich können. Verstoß
Ein riesiges Interface:
interface Multifunktionsgeraet {
void drucken();
void scannen();
void faxen();
void kopieren();
}
// SimplerDrucker MUSS alle
// Methoden implementieren,
// auch wenn er nur drucken kann!
class SimplerDrucker implements
Multifunktionsgeraet {
public void drucken() { ... }
public void scannen() {
throw new Exception();
} // sinnlos
...
Sauber
Kleine, fokussierte Interfaces:
interface Druckbar { void drucken(); }
interface Scannbar { void scannen(); }
interface Faxbar { void faxen(); }
class SimplerDrucker implements
Druckbar { ... }
class MultiFunc implements
Druckbar, Scannbar, Faxbar { ... }
// Jede Klasse nur was sie kann
In Java-APIs siehst du das oft:
Comparable, Serializable, Cloneable, Iterable – alles fokussierte Interfaces statt einer Mega-Schnittstelle. Klassen kombinieren sie nach Bedarf.6) D – Dependency Inversion Principle (DIP)
DIP – auf Abstraktionen, nicht auf Implementierungen verlassen
D
Dependency Inversion Principle
„Module hoher Ebene sollten nicht von Modulen niedriger Ebene abhängen. Beide sollen von Abstraktionen abhängen."
Statt direkt eine MySQL-Klasse zu nutzen, definiere ein
DatenbankInterface und arbeite damit. So kannst du später MySQL gegen PostgreSQL austauschen, ohne den Business-Code anzufassen. Verstoß
Harte Bindung an konkrete Klasse:
class BestellService:
def __init__(self):
self.db = MySQLDatabase()
# ↑ direkt abhängig
def speichere(self, b):
self.db.insert(b)
# Wechsel auf PostgreSQL?
# Quellcode anpassen müssen!
Sauber
Abhängigkeit injizieren:
class BestellService:
def __init__(self, db: Database):
self.db = db
# ↑ nur Interface
def speichere(self, b):
self.db.insert(b)
# DB-Implementierung von außen:
service = BestellService(MySQLDB())
# später: BestellService(PostgresDB())
# Code unverändert!
DIP führt direkt zu Dependency Injection (DI) – ein Pattern bei dem Abhängigkeiten von außen reingereicht werden, statt sie intern zu erzeugen. Modern Frameworks wie Spring (Java), Angular (TS), FastAPI (Python) bauen ihr ganzes Konzept darauf auf. Mehr in K49.
7) Praktisches Beispiel: alle 5 Prinzipien
Nehmen wir ein realistisches Szenario: ein Reporting-System. Hier verstößt der naive Code gegen mehrere SOLID-Prinzipien gleichzeitig:
1class ReportGenerator:
2 def generiere(self, daten, format):
3 # SRP-Verstoß: macht Generierung UND Formatierung UND Versand
4 if format == "pdf": # OCP-Verstoß: neues Format? if erweitern!
5 output = self._zu_pdf(daten)
6 elif format == "excel":
7 output = self._zu_excel(daten)
8 elif format == "csv":
9 output = self._zu_csv(daten)
10
11 # DIP-Verstoß: direkt MySQL-Klasse instantiiert
12 db = MySQLDB()
13 db.speichere(output)
14
15 # SRP-Verstoß: Versand gehört nicht hierher
16 SMTPClient().sende("admin@firma.de", output)
Die saubere Variante mit allen SOLID-Prinzipien angewandt:
1# ISP: kleine Interfaces
2class Formatter(Protocol):
3 def formatiere(self, daten) -> bytes: ...
4
5class Storage(Protocol):
6 def speichere(self, data: bytes): ...
7
8# OCP/SRP: jeder Formatter ist eigene Klasse
9class PdfFormatter:
10 def formatiere(self, daten): return ...
11
12class CsvFormatter:
13 def formatiere(self, daten): return ...
14
15# DIP: Abhängigkeiten von außen, nur Interfaces
16class ReportGenerator:
17 def __init__(self, fmt: Formatter, storage: Storage):
18 self.fmt = fmt
19 self.storage = storage
20
21 def generiere(self, daten):
22 output = self.fmt.formatiere(daten)
23 self.storage.speichere(output)
Vorteile: neuer Formatter? Klasse JsonFormatter dazu, ReportGenerator bleibt unverändert. DB tauschen? Andere Storage-Klasse reinreichen. Tests? Mock-Klassen statt MySQL nutzen.
8) Wann SOLID übertrieben ist
Wichtig zu wissen: SOLID kann auch übertrieben werden. Wenn du für ein 50-Zeilen-Skript fünf Interfaces und Dependency Injection einbaust, hast du Over-Engineering. Gute Faustregeln:
- Kleine Skripte und Prototypen: SOLID meist Overhead. Direkt und einfach reicht.
- Mittlere Apps: SRP und OCP konsequent anwenden, andere nach Bedarf.
- Große, langlebige Systeme: alle 5 Prinzipien wichtig. Lieber etwas mehr Code zu Beginn als später unwartbar.
Auch das Gegenteil ist wahr: wenn dein Code sich nicht ändert, brauchst du keine Erweiterbarkeit. You aren't gonna need it (YAGNI) ist ein Gegenprinzip. Die Kunst: das richtige Maß finden.
9) Self-Check: ist mein Code SOLID?
Checkliste für eigenen Code
Kann ich jede Klasse mit einem Satz beschreiben, ohne „und" zu verwenden?
Hat jede Klasse weniger als ~200 Zeilen? Größere sind oft SRP-Verstöße.
Habe ich große if-elif-else-Blöcke die nach Typ unterscheiden? → potentieller OCP-Verstoß.
Wenn morgen ein neuer Typ dazukommt – muss ich bestehenden Code anfassen? Wenn ja, OCP nicht erfüllt.
Überschreiben Unterklassen Methoden so, dass sie Exceptions werfen oder andere Verhalten haben als erwartet? → LSP verletzt.
Haben meine Interfaces mehr als 5-7 Methoden? → Eventuell aufteilen.
Gibt es Klassen die Interface-Methoden mit „not implemented" oder leerer Implementation füllen?
Verwende ich
new ConcreteClass() in meiner Business-Logik? → Eventuell injizieren.Kann ich meine Klassen isoliert testen, ohne echte DB/API zu starten?
Diese Checkliste ist nicht absolut. Manchmal sind Verstöße bewusst und sinnvoll. Aber wenn du mehrere dieser Punkte hast, lohnt sich Refactoring.
10) Häufige Klausurfragen
SOLID kommt in IHK-Prüfungen, Hochschulklausuren und Bewerbungsgesprächen. Die wichtigsten Fragen:
- „Wofür steht SOLID?" → Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
- „Was bedeutet S in SOLID?" → eine Klasse, eine Verantwortung, ein Grund zur Änderung
- „Was bedeutet OCP?" → offen für Erweiterung (neue Klassen), geschlossen für Modifikation (kein Anfassen bestehenden Codes)
- „Wer war Liskov?" → Barbara Liskov, Turing-Award-Gewinnerin, hat das Prinzip formuliert
- „Beispiel für LSP-Verstoß?" → Pinguin erbt von Vogel, kann aber nicht fliegen; Quadrat erbt von Rechteck
- „Was sagt ISP?" → kleine Interfaces statt großer; Klienten nicht zwingen unbenötigte Methoden zu implementieren
- „Wie hängt DIP mit Dependency Injection zusammen?" → DIP ist das Prinzip („auf Abstraktionen verlassen"), DI ist die Technik (Abhängigkeiten von außen reinreichen)
- „Wer hat SOLID populär gemacht?" → Robert C. Martin („Uncle Bob"), frühe 2000er, fasste bestehende Ideen zusammen
Zusammenfassung
SOLID = 5 Designprinzipien für wartbaren OOP-Code von Robert C. Martin. S Single Responsibility: eine Klasse, eine Verantwortung. O Open/Closed: offen für Erweiterung (neue Klassen), geschlossen für Modifikation (kein Anfassen). L Liskov Substitution: Unterklassen müssen ohne Bruch für Oberklassen einsetzbar sein. I Interface Segregation: kleine fokussierte Interfaces statt großer. D Dependency Inversion: Code soll von Abstraktionen abhängen, nicht von konkreten Implementierungen → führt zu Dependency Injection. SOLID-Konformität führt zu testbarem, erweiterbarem Code. Aber: nicht überall sinnvoll – für Skripte Overhead, für große Systeme essentiell. Klausurthema in IHK, Hochschule und Bewerbungsgesprächen.