update

Writerside/in.tree

@@ -34,6 +34,10 @@
                     <toc-element topic="UMLStateDiagramme.md"/>
                 </toc-element>
                 <toc-element topic="AgileDesign.md"/>
+                <toc-element topic="DesignPrinciples.md">
+                    <toc-element topic="SOLID-Principle.md"/>
+                </toc-element>
+                <toc-element topic="DesignPatterns.md"/>
             </toc-element>
         </toc-element>
         <toc-element toc-title="Rechnerarchitektur">
@@ -65,4 +69,5 @@
             <toc-element topic="7_BusinessModelCanvas.md"/>
         </toc-element>
     </toc-element>
+
 </instance-profile>

Writerside/topics/OOAD/AgileDesign.md

@@ -52,4 +52,35 @@
     - Devs entscheiden zwischen Designerhaltung und einfacher Lösung
     - Design sollte design erhaltende Änderungen fördern
 2. Viskosität der Umgebung
-    - h
+    - Umgebungen, die einfache statt design erhaltende Änderungen
+    - Lange compile Zeiten verringern Lust auf recompilen
+    - Lange VCS-Check-ins verringern Check-ins
+
+### Needless Complexity 
+- Ein Design enthält Elemente, die momentan nicht nützlich sind
+- Passiert häufig, wenn Devs Änderungen erwarten
+  - Vorbereitung für zukünftigen Code
+  - Das Design muss das Gewicht dieser Elemente nun mittragen
+  - Manche Vorbereitungen sind nützlich, aber nicht alle
+- Software wird komplex
+
+### Needless Repetition
+- Copy Paste sollte nicht benutzt werden
+  - Wenn Code mehrfach in minimal unterschiedlichen Formen vorkommt
+    - Devs haben Abstraktion vergessen
+    - Wiederholungen sollten gefunden und beseitigt werden
+- Wiederholender Code macht Änderungen schwierig
+  - Bugs müssen in allen Wiederholungen geändert werden
+  - Änderungen nicht immer gleich in allen
+
+
+### Opacity
+- Code ist in einer unverständlichen Art geschrieben
+  - Häufig in Code der über Zeit weiterentwickelt wird
+- Benötigt konstanten Einsatz den Code clean zu halten
+  - Wenn Code das erste Mal geschrieben wird, scheint er clean
+    - Verständnis auf intimer Ebene
+- Devs müssen aus der Sicht eines Außenstehenden gucken
+  - Refactor bis Leser es verstehen können
+  - Code von anderen lesen lassen
+

Writerside/topics/OOAD/DesignPatterns.md

@@ -0,0 +1,18 @@
+# Design Patterns
+- Typische Lösung für häufige Probleme im Software Design
+  - Kein Code, nur Lösungsansatz
+- Gute OO-Designs sind wiederverwendbar, erweiterbar, wartbar
+
+## Typen von Design Patterns
+- **Creational Patterns**
+  - Objekterstellungsmechanismen → erhöhen Flexibilität
+- **Strukturelle Pattern**
+  - Objekte anwenden und Klassen in größeren Strukturen gruppieren ohne Flexibilität einzubußen
+- **Behavioral Patterns**
+  - Algorithmen und Zuordnung von Verantwortlichkeiten
+
+## How to use a design pattern
+- Bibliotheken
+
+## Observer Pattern
+- 

Writerside/topics/OOAD/DesignPrinciples.md

@@ -0,0 +1,29 @@
+# Design Principles
+## [SOLID Design Principles](SOLID-Principle.md)
+- Fokus auf der Erstellung von Code
+- Wartbar, Robust, Wiederverwendbar
+
+### S - Single Responsibility Principle (SRP)
+- Eine Klasse sollte nur eine einzige Aufgabe / Verantwortung haben 
+### O - Open/Closed Principle (OCP)
+- Software Komponenten sollten nur fpr Erweiterung, nicht für Modifikation offen sein
+### L - Liskov's Substitution Principle (LSP)
+- Basisklassen müssen komplett passend für die erbenden Klassen sein
+### I - Interface Segregation Principle (ISP)
+- Clients sollten nicht dazu verpflichtet werden unnötige Methoden zu implementieren
+### D - Dependency Inversion Principle (DIP)
+- Abhängig von Abstraktion, nicht Konkretion
+
+
+## Favor Composition over Inheritance
+- Vererbung ist ein offensichtlicher Weg um Code von der Basisklasse wiederzuverwenden
+- Unterklassen können die Codebasis der Basisklassen nicht verkleinern
+  - Methoden des Interfaces müssen alle implementiert werden
+
+### Composition
+- Inheritance: _is-a relationship_
+- Composition
+  - _contains relationship_
+- Prinzip kann auch auf Aggregation angewendet werden
+- ![image_374.png](image_374.png)
+

Writerside/topics/OOAD/Praktikum3_Diagramme.md

@@ -22,12 +22,13 @@ classDiagram
 
     Tourguide --|> Person
     Participant --|> Person
-    Trip "1..*" *-- "1..*" AdventurePackage
+Trip "1..*" o-- "1..*" AdventurePackage
-    Trip "*" *-- "1" Accommodation
+Trip "*" o-- "1" Accommodation
-    Participant "1..*" -- Booking
+Participant "1..*" -- "1..*" Trip: Booking
-    Booking "1..*" -- "1..*" Trip
+Participant "1..*" .. Booking
-    Tourguide "1" --* "*" Trip
+Booking "1..*" .. "1..*" Trip
-    Tourguide "1..*" -- "1..*" AdventurePackage
+Tourguide "1" --o "*" Trip
+Tourguide "1..*" -- "1..*" AdventurePackage
 ```
 
 
@@ -67,8 +68,9 @@ sequenceDiagram
     LibGui ->>+ EBook: generateLink()
     EBook --)- LibGui: return link
 
-    LibGui ->>+ CTom: showLink()
+    activate LibGui
-    CTom --)- LibGui: return
+    LibGui ->> LibGui: showLink()
+    LibGui --)- LibGui: return
 
     LibGui --) Tom: return
 

Writerside/topics/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
+