diff --git a/Writerside/images/image_364.png b/Writerside/images/image_364.png new file mode 100644 index 0000000..6c555a9 Binary files /dev/null and b/Writerside/images/image_364.png differ diff --git a/Writerside/images/image_365.png b/Writerside/images/image_365.png new file mode 100644 index 0000000..4849917 Binary files /dev/null and b/Writerside/images/image_365.png differ diff --git a/Writerside/images/image_366.png b/Writerside/images/image_366.png new file mode 100644 index 0000000..4a3dc11 Binary files /dev/null and b/Writerside/images/image_366.png differ diff --git a/Writerside/images/image_367.png b/Writerside/images/image_367.png new file mode 100644 index 0000000..f486fe7 Binary files /dev/null and b/Writerside/images/image_367.png differ diff --git a/Writerside/images/image_368.png b/Writerside/images/image_368.png new file mode 100644 index 0000000..183eca2 Binary files /dev/null and b/Writerside/images/image_368.png differ diff --git a/Writerside/images/image_369.png b/Writerside/images/image_369.png new file mode 100644 index 0000000..b1a6513 Binary files /dev/null and b/Writerside/images/image_369.png differ diff --git a/Writerside/images/image_370.png b/Writerside/images/image_370.png new file mode 100644 index 0000000..a70948c Binary files /dev/null and b/Writerside/images/image_370.png differ diff --git a/Writerside/images/image_371.png b/Writerside/images/image_371.png new file mode 100644 index 0000000..b6dc8b3 Binary files /dev/null and b/Writerside/images/image_371.png differ diff --git a/Writerside/images/image_372.png b/Writerside/images/image_372.png new file mode 100644 index 0000000..c4221b8 Binary files /dev/null and b/Writerside/images/image_372.png differ diff --git a/Writerside/images/image_373.png b/Writerside/images/image_373.png new file mode 100644 index 0000000..84909b3 Binary files /dev/null and b/Writerside/images/image_373.png differ diff --git a/Writerside/images/image_374.png b/Writerside/images/image_374.png new file mode 100644 index 0000000..eacb2aa Binary files /dev/null and b/Writerside/images/image_374.png differ diff --git a/Writerside/in.tree b/Writerside/in.tree index 3fd18d1..08459ec 100644 --- a/Writerside/in.tree +++ b/Writerside/in.tree @@ -34,6 +34,10 @@ + + + + @@ -65,4 +69,5 @@ + \ No newline at end of file diff --git a/Writerside/topics/OOAD/AgileDesign.md b/Writerside/topics/OOAD/AgileDesign.md index 2bfdc0e..3d60080 100644 --- a/Writerside/topics/OOAD/AgileDesign.md +++ b/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 \ No newline at end of file + - 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 + diff --git a/Writerside/topics/OOAD/DesignPatterns.md b/Writerside/topics/OOAD/DesignPatterns.md new file mode 100644 index 0000000..50510cb --- /dev/null +++ b/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 +- \ No newline at end of file diff --git a/Writerside/topics/OOAD/DesignPrinciples.md b/Writerside/topics/OOAD/DesignPrinciples.md new file mode 100644 index 0000000..6677fa2 --- /dev/null +++ b/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) + diff --git a/Writerside/topics/OOAD/Praktikum3_Diagramme.md b/Writerside/topics/OOAD/Praktikum3_Diagramme.md index 48d7206..2a5c203 100644 --- a/Writerside/topics/OOAD/Praktikum3_Diagramme.md +++ b/Writerside/topics/OOAD/Praktikum3_Diagramme.md @@ -2,8 +2,8 @@ classDiagram class Person <> Person - Person : - name - Person : - adress + Person : - name + Person : - adress class Tourguide Tourguide : - certifiedAdventurePackages vector class Participant @@ -15,19 +15,20 @@ classDiagram Accommodation : - adress class Trip Trip : - startingDate - + class Booking Booking : - payed Booking : - dateOfBooking - + Tourguide --|> Person Participant --|> Person - Trip "1..*" *-- "1..*" AdventurePackage - Trip "*" *-- "1" Accommodation - Participant "1..*" -- Booking - Booking "1..*" -- "1..*" Trip - Tourguide "1" --* "*" Trip - Tourguide "1..*" -- "1..*" AdventurePackage +Trip "1..*" o-- "1..*" AdventurePackage +Trip "*" o-- "1" Accommodation +Participant "1..*" -- "1..*" Trip: Booking +Participant "1..*" .. Booking +Booking "1..*" .. "1..*" Trip +Tourguide "1" --o "*" Trip +Tourguide "1..*" -- "1..*" AdventurePackage ``` @@ -67,8 +68,9 @@ sequenceDiagram LibGui ->>+ EBook: generateLink() EBook --)- LibGui: return link - LibGui ->>+ CTom: showLink() - CTom --)- LibGui: return + activate LibGui + LibGui ->> LibGui: showLink() + LibGui --)- LibGui: return LibGui --) Tom: return diff --git a/Writerside/topics/OOAD/SOLID-Principle.md b/Writerside/topics/OOAD/SOLID-Principle.md new file mode 100644 index 0000000..b806194 --- /dev/null +++ b/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 +