Willkommen › Software Architecture › SOLID-Prinzipien
Software Architecture · SOLID-Prinzipien
SOLID: fünf Regeln für Code, der mitwächst.
Die SOLID-Prinzipien von Robert C. Martin sind die Grundlage für wartbare, objektorientierte Software. Wir erklären sie verständlich – und wenden sie in jedem Projekt an.
Die fünf Prinzipien
S · O · L · I · D
Single Responsibility
Eine Klasse hat genau einen Grund, sich zu ändern. Rechnung erstellen und Rechnung mailen sind zwei Aufgaben.
Open/Closed
Offen für Erweiterung, geschlossen für Änderung: Neues kommt dazu, ohne Bestehendes umzubauen.
Liskov Substitution
Eine Unterklasse muss sich überall wie ihre Oberklasse verwenden lassen – ohne Überraschungen.
Interface Segregation
Lieber mehrere kleine Schnittstellen als eine große, von der jeder nur die Hälfte braucht.
Dependency Inversion
Hänge von Abstraktionen ab, nicht von konkreten Klassen – so bleibt Code testbar und austauschbar.
Beispiel
Dependency Inversion in der Praxis.
Die Klasse Anmeldung weiß nicht, ob Mails per SMTP, über einen Newsletter-Dienst oder im Test gar nicht verschickt werden. Sie kennt nur die Schnittstelle Mailer.
Im Test übergeben wir einen Fake-Mailer – kein Mailserver nötig, Tests laufen in Millisekunden.
interface Mailer { senden(an: string, text: string): void; }
class Anmeldung {
// haengt von der Abstraktion ab, nicht von SMTP
constructor(private mailer: Mailer) {}
registrieren(email: string) {
// ... Konto anlegen ...
this.mailer.senden(email, "Willkommen bei it7days!");
}
}Code-Review
So prüfen wir Code auf SOLID.
Sauberer Code ist kein Luxus.
1
Abhängigkeiten sichtbar machen
Welche Klasse kennt welche? Wir zeichnen die Struktur, bevor wir sie ändern.
2
Gerüche finden
Riesige Klassen, lange Parameterlisten, switch über Typen – typische Hinweise auf verletzte Prinzipien.
3
In kleinen Schritten verbessern
Mit Tests als Sicherheitsnetz refaktorieren wir schrittweise, ohne Funktionen zu brechen.
Im Detail
Woran man verletzte Prinzipien erkennt.
- Riesige Klassen – Hinweis auf zu viele Verantwortlichkeiten (S)
- Switch über Typen – neue Fälle erzwingen Änderungen an alter Logik (O)
- Überraschende Unterklassen – Methoden werfen „nicht unterstützt“-Fehler (L)
- Leere Methoden – Klassen müssen Schnittstellen erfüllen, die sie nicht brauchen (I)
- new überall – konkrete Klassen statt Abstraktionen erschweren Tests (D)
- Lange Parameterlisten – oft ein Zeichen für vermischte Aufgaben
- Globale Zustände – versteckte Abhängigkeiten zwischen Programmteilen
- Schwer testbar – wenn ein Unit-Test eine Datenbank braucht, stimmt etwas nicht
- Schrotflinten-Änderungen – eine kleine Änderung erfordert Anpassungen in vielen Dateien
- Kommentare als Pflaster – „Achtung, nicht anfassen!“ statt sauberem Design
Du brauchst uns, wenn …
Sauberer Code ist kein Luxus.
Dein Code ist gewachsen – und unübersichtlich geworden?
Wir schauen uns deine Anwendung an und zeigen dir, wo sich Aufräumen am meisten lohnt.