zusammenfassungen/Writerside/topics/02/OOAD/SOLID-Principle.md

SOLID

S - Single Responsibility Principle (SRP)

• Änderungen entstehen, wo Verantwortung ist
  • Verantwortung ist ein Grund zur Änderung
• Falls eine Klasse mehr als eine Verantwortung hat
  • Verantwortungen werden gruppiert :(
    • Führt zu fragilem Design

Beispiel SRP Verletzung

• 
• Erzeugte Probleme
  • GUI muss in computionalGeometryApplication inkludiert werden
  • Änderungen in Graphical führen zu Änderungen in computional
• Besser:
  • 

Was ist eine Responsibility

• Ein Grund zur Änderung
• Wenn jemandem mehr als eine Idee einfällt, warum man die Klasse ändern könnte
  • Mehrere Responsibilitys

O - Open/Closed Principle (OCP)

• Änderungen an einzelnen Dateien sollen sich nicht auf andere Klassen auswirken
• Lieber neuen Code statt Code zu ändern, der funktioniert
• Wird durch Abstraktion erreicht
  • Abstraktion ist nach außen fest
  • Geerbte Klassen können Methoden neu zu ihren Bedürfnissen anpassen

Beispiel OCP Verletzung

• 
  • Client nutzt Server Klasse
    • Falls Server sich clientseitig ändert gehts teilweise nicht mehr
• Besser:
  • 

Wann OCP anwenden?

• Gegen welche Änderungen möchte man sich schützen?
  • Nicht gegen die falschen Änderungen
    • häufig falsch, aber passiert
• Häufig unnötig → Needless Complexity

L - Liskov's Substitution Principle (LSP)

• Subtypen müssen passend zu ihren Basisklassen sein
• Macht OCP besser

Beispiel LSP Verletzung

• 
  • Pinguin kann nicht fliegen → :(
• Besser:
  • 

I - Interface Segregation Principle (ISP)

• Niemanden dazu zwingen Interfaces zu nutzen
• 

Beispiel ISP Verletzung

• 
• Besser
  • 

Conclusion ISP

• Fette Klassen erzeugen schädigende Kupplung zwischen ihren Klienten

D - Dependency Inversion Principle (DIP)

• Abstraktionen sollten nicht von Details abhängig sein
• DIP behandelt Besitztum und Abhängigkeiten
  • Detaillierte Implementierungen definieren die Abstraktion, von der sie abhängig sind

Naive Layering System

• High Level Policy Layer
• Lower Level Mechanism Layer
• Detailed Level Utility Layer

Inversion of Ownership

• 

When to use the DIP?

• Nichts sollte von einer konkreten Klasse abhängig sein
• Keine Variable sollte einen Pointer auf eine andere Klasse enthalten
• Keine Methode sollte eine bereits implementierte Methode seiner Basisklasse überschreiben

Conclusion DIP

• Sowohl Policies als auch Detail basieren auf Abstraktion
  • Fundamentaler low-level Mechanismus hinter OOAD