Programming Principles
SOLID
Single Responsibility Principle
- jede Klasse hat nur eine Zuständigkeit
Open Closed Principle
- offen für Erweiterungen
- geschlossen für Änderungen
Liskov Substitution Principle
- Objekte eines abgeleiteten Typs müssen als Ersatz ihres Basistyps funktionieren, ohne die Korrektheit zu ändern.
Interface Segregation Principle
- 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
Dependency Inversion Principle
- 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
Tell, don't ask
- Objekt selbst etwas ausführen lassen
→ hat alle Informationen um Entscheidungen selbst zu treffen - Kommandos statt Abfragen
→ Führt zu verteilter Businesslogik
KISS
"Keep it simple, stupid"
- Komplexität so gering wie möglich halten
- Code nicht unnötig verkomplizieren
SLAP
"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
DRY
"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
YAGNI
"You ain't gonna need it"
- nicht benötigte Features nicht implementieren
- unnötige Features erhöhen Komplexität
- bindet unnötig Ressourcen
GRASP
"General Responsibility Assignment Software Patterns"
Ziel: Low Representational Gap (LRG) möglichst klein halten
(LRG = Lücke zwischen gedachtem Domänenmodell und Implementierung)
Low Coupling
- geringe Kopplung zwischen Objekten
- Abhängigkeiten so gering wie möglich halten
High Cohesion
- starke Kohäsion innerhalb einer Klasse
- semantische Nähe der Elemente einer Klasse
Information Expert
- Objekt hält Verantwortung für Informationen die es besitzt
- Objekte sind zuständig für Aufgaben die ihre Informationen betreffen
Creator
- 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
Indirection
- Delegation
- kann Teile des Systems entkoppeln, indem Aufgaben ausgelagert werden
Polymorphism
- Behandlung von alternativen abhängig vom Typ
- Umgang mit Variation in der OO-Programmierung
- Methoden je nach Typ andere Implementierung
- Vermeidung von Fallunterscheidungen
Controller
- Verarbeitung einkommender Benutzereingaben
- Koordination UI ↔ Logik
- Hauptsächlich Delegation
- Verwalten des Anwendungszustands
Pure Fabrication
- reine Verhalten- oder Arbeiterklasse
- keinen Bezug zur Domäne
- Trennung technisch ↔ fachlich
Protected Variations
- Kapselung verschiedener Implementierungen hinter einer einheitlichen API
- Variabilität einzelner Komponenten soll nicht Gesamtsystem beeinflussen
Conways Law
- Kommunikationsstruktur eines Unternehmens bildet sich auf Code bzw. Architektur ab
- Kommunikationsschnittstellen entsprechen Modulschnittstellen im Code
- Besser: Kommunikationsstruktur an Produkt/Kundenbedürfnis ausrichten