- jede Klasse hat nur eine Zuständigkeit
- offen für Erweiterungen
- geschlossen für Änderungen
- Objekte eines abgeleiteten Typs müssen als Ersatz ihres Basistyps funktionieren, ohne die Korrektheit zu ändern.
- Interfaces aufteilen, sodass Funktionalität getrennt ist
- Fat Interfaces bündeln viel Funktionalität:
- Anwender abhängig von Änderungen anderer Methoden im Interface
- Anwender hat Zugriff auf Methoden, die nicht für ihn bestimmt sind
- High-Level-Module sollten nicht von Low-Level-Modulen abhängen
- Regeln in High-Level-Modul vorgegeben, in Low-Level-Modul implementiert
- ausschließlich von Abstraktionen abhängen
→ High-Level-Module können so wiederverwendet werden
- Objekt selbst etwas ausführen lassen
→ hat alle Informationen um Entscheidungen selbst zu treffen - Kommandos statt Abfragen
→ Führt zu verteilter Businesslogik
"Keep it simple, stupid"
- Komplexität so gering wie möglich halten
- Code nicht unnötig verkomplizieren
"Single Level of Abstraction Principle"
- Code innerhalb einer Methode ist auf einem Abstraktionsniveau
- keine Vermischung von Arbeit und Delegation
- keine Vermischung aus Technischem und Businesslogik
→ Composed Methods: Einstiegsmethode delegiert an private Hilfsmethoden
"Don't repeat yourself"
- Code nur einmal schreiben
- gleicher Code auslagern und von allen anderen Stellen darauf zugreifen
- Änderungen müssen nur an einer Stelle gemacht werden
- Nur eine Quelle der Wahrheit
"You ain't gonna need it"
- nicht benötigte Features nicht implementieren
- unnötige Features erhöhen Komplexität
- bindet unnötig Ressourcen
"General Responsibility Assignment Software Patterns"
Ziel: Low Representational Gap (LRG) möglichst klein halten
(LRG = Lücke zwischen gedachtem Domänenmodell und Implementierung)
- geringe Kopplung zwischen Objekten
- Abhängigkeiten so gering wie möglich halten
- starke Kohäsion innerhalb einer Klasse
- semantische Nähe der Elemente einer Klasse
- Objekt hält Verantwortung für Informationen die es besitzt
- Objekte sind zuständig für Aufgaben die ihre Informationen betreffen
- Legt fest, wer für die Erzeugung von Objekten zuständig ist
- Objekt kommt als Creator infrage, wenn es zu jedem erstellten Objekt eine Beziehung hat
- Delegation
- kann Teile des Systems entkoppeln, indem Aufgaben ausgelagert werden
- Behandlung von alternativen abhängig vom Typ
- Umgang mit Variation in der OO-Programmierung
- Methoden je nach Typ andere Implementierung
- Vermeidung von Fallunterscheidungen
- Verarbeitung einkommender Benutzereingaben
- Koordination UI ↔ Logik
- Hauptsächlich Delegation
- Verwalten des Anwendungszustands
- reine Verhalten- oder Arbeiterklasse
- keinen Bezug zur Domäne
- Trennung technisch ↔ fachlich
- Kapselung verschiedener Implementierungen hinter einer einheitlichen API
- Variabilität einzelner Komponenten soll nicht Gesamtsystem beeinflussen
- Kommunikationsstruktur eines Unternehmens bildet sich auf Code bzw. Architektur ab
- Kommunikationsschnittstellen entsprechen Modulschnittstellen im Code
- Besser: Kommunikationsstruktur an Produkt/Kundenbedürfnis ausrichten