| Typ | Konzept |
|---|---|
| Quellen | Quelle - Effektive Softwarearchitekturen |
| Erstellt | 2026-09-27 |
| Aktualisiert | 2026-09-27 |
| Tags | softwarearchitektur, entwurf, kopplung, kohäsion, solid, kiss, dry, information-hiding |
Erfahrungsregeln für guten Softwareentwurf: grundsätzliche Maximen wie KISS und „No Silver Bullet“, Prinzipien wie lose Kopplung, hohe Kohäsion, Trennung der Verantwortlichkeiten, Information Hiding, DRY und keine zyklischen Abhängigkeiten sowie die SOLID-Prinzipien. Man muss sie gegen die konkreten Anforderungen abwägen.
Warum Prinzipien?
Ohne sie verfault ein Entwurf. Die Symptome sind Starrheit (jede Änderung zieht weitere nach sich), Zerbrechlichkeit (Änderungen erzeugen Fehler an unerwarteten Stellen) und schlechte Wiederverwendbarkeit (Quelle - Effektive Softwarearchitekturen, S. 60). Langfristig führt das zu technischen Schulden.
Maximen
Die obersten Grundsätze (S. 62–64):
- Stakeholder beurteilen den Erfolg, nicht der Architekt („Business drives technology“).
- KISS, Einfachheit gewinnt: „Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann“ (Saint-Exupéry). Die Bausteine mit den wenigsten Fehlern sind die, die man weglassen konnte.
- Entscheide spezifisch („No Silver Bullet“): Es gibt kein Patentrezept.
- Explizit statt implizit: Annahmen, Verantwortlichkeiten und Qualitätsziele ausschreiben.
- Erwarte Änderungen, aber übertreibe es nicht: Hoch konfigurierbare Systeme sind schwerer zu testen.
- Erwarte Fehler (Murphy): Auswirkungen lokal halten.
- Continuous Compliance: Die wichtigsten Qualitätsziele laufend prüfen (Softwarequalität).
Prinzipien
Das erste Prinzip: Wäge Prinzipien gegen Anforderungen ab. Lose Kopplung kann z. B. die Performance kosten (S. 65).
| Prinzip | Kern |
|---|---|
| Lose Kopplung | wenige, bewusst gesetzte Abhängigkeiten. Kopplungsarten: Aufruf, Benachrichtigung, Erzeugung, Daten, Hardware/Laufzeitumgebung, Zeit (S. 65–66) |
| Hohe Kohäsion | was zusammengehört, steht zusammen; jeder Baustein hat eine klare Aufgabe |
| Trennung der Verantwortlichkeiten (Separation of Concerns) | Fachlichkeit und Technik trennen, eine Aufgabe pro Baustein |
| Modularität, Information Hiding | nach David Parnas (1972): Bausteine verbergen ihr Inneres hinter einer Schnittstelle, das „Was“ getrennt vom „Wie“ (S. 68) |
| Konsistenz, konzeptionelle Integrität | ähnliche Probleme ähnlich lösen. Gegenbeispiel: sieben verschiedene XML-Parser in einem System (S. 69) |
| DRY, Single Source of Truth | jede Information nur an einer Stelle (S. 69) |
| Keine zyklischen Abhängigkeiten | Zyklen machen Bausteine untrennbar |
| Angemessen erklären | Entwurf verständlich halten |
Die Kopplung lässt sich im Quellcode messen. Steigt sie deutlich, sollte man umstrukturieren (S. 66, Architekturbewertung).
SOLID
Die fünf Prinzipien des objektorientierten Entwurfs nach Robert C. Martin (S. 71–78):
| Prinzip | Kern | |
|---|---|---|
| S | Single Responsibility | eine Klasse hat nur einen Grund, geändert zu werden |
| O | Open-Closed | offen für Erweiterung, geschlossen für Änderung |
| L | Liskov Substitution | Unterklassen müssen überall anstelle ihrer Oberklasse funktionieren |
| I | Interface Segregation | kleine, auf den Nutzer zugeschnittene Schnittstellen statt einer Universalschnittstelle |
| D | Dependency Inversion | von Abstraktionen abhängen, nicht von Implementierungen. Umgesetzt oft mit Dependency Injection |
Entwurfsheuristiken
Neben Prinzipien nennt Starke Faustregeln für das Vorgehen (S. 79–84). Eine Heuristik ist für ihn „die Kunst (nicht Wissenschaft, nicht Prozess) mit unvollständigen Informationen zu angemessenen Lösungen zu kommen“. Mit Eberhardt Rechtin: Die Kunst liegt darin, die passende Heuristik für das jeweilige Projekt auszuwählen (S. 79). Starkes Heuristiken:
- gründlich recherchieren: erfolgreiche und gescheiterte Lösungen suchen, Experten finden;
- Versuch und Irrtum: „We don't know what works until we try it“ (Tom Gilb). Prototypen, TDD und BDD machen das systematisch, danach wird bewertet (Softwaretest, Prototyping);
- generalisieren (Spezialfälle zusammenfassen) und spezialisieren (erst der Sonnenscheinfall, dann ein einfacher Fehler, dann der schlimmste Fall);
- die Perspektive wechseln: fachlich, Oberfläche und User Experience, Laufzeitmessung;
- Fachlichkeit und Technik trennen (Domain-Driven Design);
- auf Schnittstellen achten: Dort stecken die wichtigsten Probleme (Rechtin).
Warum hier Heuristiken statt Algorithmen nötig sind, beschreibt Heuristiken in BWL und Informatik.
Schnittstellen
Schnittstellen sind die Verträge zwischen Bausteinen (design by contract, S. 21). Riskante Schnittstellen sollte man früh angehen und klar einer verantwortlichen Person zuweisen. Tipps des Buches, teils nach Josh Bloch (S. 103):
- die eigene Schnittstelle selbst benutzen, etwa in Tests („eat your own dogfood“);
- Anforderungen mit Nutzer (Consumer) und Anbieter (Provider) klären;
- Implementierungsdetails verbergen (Geheimnisprinzip);
- sprechende Namen konsequent verwenden.
Verwandt
- Softwarearchitektur – wo die Prinzipien angewendet werden
- Entwurfsmuster – konkrete Lösungen, die Prinzipien umsetzen
- Architekturstil – Prinzipien im Grossen
- Dependency Injection – Umsetzung des Dependency-Inversion-Prinzips
- Domain-Driven Design – Fachlichkeit von Technik trennen
- Angular-Architektur – dieselben Prinzipien in einer Frontend-Anwendung