# 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](AgileDesign.md#fragility-zerbrechlichkeit)

### Beispiel SRP Verletzung
- ![image_364.png](image_364.png)
- Erzeugte Probleme
  - GUI muss in computionalGeometryApplication inkludiert werden
  - Änderungen in Graphical führen zu Änderungen in computional
- Besser:
  - ![image_365.png](image_365.png)

### 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
- ![image_366.png](image_366.png)
  - Client nutzt Server Klasse
    - Falls Server sich clientseitig ändert gehts teilweise nicht mehr
- Besser:
  - ![image_367.png](image_367.png)

### 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](AgileDesign.md#needless-complexity)


## L - Liskov's Substitution Principle (LSP)
- Subtypen müssen passend zu ihren Basisklassen sein
- Macht OCP besser

### Beispiel LSP Verletzung
- ![image_368.png](image_368.png)
  - Pinguin kann nicht fliegen → :(
- Besser:
  - ![image_369.png](image_369.png)


## I - Interface Segregation Principle (ISP)
- Niemanden dazu zwingen Interfaces zu nutzen
- ![image_371.png](image_371.png)

### Beispiel ISP Verletzung
- ![image_372.png](image_372.png)
- Besser
  - ![image_373.png](image_373.png)

### 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
- ![image_370.png](image_370.png)

### 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