update

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

@@ -0,0 +1,90 @@
+# 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
+