update

Writerside/topics/OOAD/DesignPatterns.md

@@ -15,4 +15,168 @@
 - Bibliotheken
 
 ## Observer Pattern
+- One-To-Many Abhängigkeit
+  - Wenn ein Objekt sich ändert
+  - Alle Abhängigkeiten werden benachrichtigt
+
+### Nutzung Observer Pattern
+- Wenn Zustandsänderung eines Objekts Änderung in anderen Objekten hervorruft
+- Wenn Objekte etwas beobachten müssen für eine bestimmte Zeit/Fall
+
+### Beispiel Observer Pattern
+- Kunden über Verfügbarkeit von Produkten informieren
+  - 2 Typen von Objekten: Kunde, Markt
+
+#### Pull
+- Kunde fragt häufiger nach, ob es da ist
+  - Meistens: NEIN
+
+#### Push
+- Markt schreibt alle Kunden an, sobald ein Produkt verfügbar ist
+  - Auch die, die kein Interesse haben
+
+#### Observer
+- Jedes Produkt hat eine Liste von Subscribern
+  - Sobald sich Verfügbarkeit ändert alle benachrichtigen
+
+### Struktur Observer Pattern
+![image_375.png](image_375.png)
+#### Subject (Interface)
+- Kennt seine Beobachter
+
+#### Observer (Interface)
+- Definiert Interface für Objekte, welche benachrichtigt werden sollen
+
+#### ConcreteSubject
+- Speichert Daten (oder Zustand) der Interesse
+- Sendet Benachrichtigung bei Änderung 
+
+#### Concrete Observer
+- Behält Referenz zu ConcreteSubject
+- Gespeicherter Zustand bleibt gleich mit Subject-Zustand
+  - Implementiert das update-Interface des Observers
+
+### Fazit Observer Pattern
+- Wird gefördert durch das [OPC](SOLID-Principle.md#o-open-closed-principle-ocp)
+- [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp) wird angewendet
+- [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip) wird angewendet
+- [ISP](SOLID-Principle.md#i-interface-segregation-principle-isp) wird manchmal angewendet
+  - Manchmal kann eine Klasse Observer und Subjekt sein
+
+
+## Factory Method (Virtual Constructor)
+- Interface für die Erstellung eines Objekts
+  - Lässt Subklassen entscheiden welche Klassen instanziiert wird
+- Ersteller Klassen wissen nicht von den tatsächlichen Objekten
+
+### Struktur Factory Method
+![image_376.png](image_376.png)
+#### Product (Abstract Class / Interface)
+- Definiert üblichen Typ der Objekte
+- Abstraktion, welche von der restlichen Codebase genutzt wird
+
+#### Concrete Product(s)
+- Implementierung des Produkt-Interface
+
+#### Creator (Abstract Class)
+- Deklariert Factory-Methode
+  - Gibt Objekt zurück
+- Kann noch andere Methoden enthalten
+
+#### ConcreteCreator
+- Jedes semantische Produkt hat seinen eigenen ConcreteCreator
+  - Überschreiben der Factory-Methode
+  - Implementierung der Kreation der spezifischen Produkte
+- Mehrere ConcreteCreator können ein ConcreteProduct erstellen (bspw. verschiedene Werte)
+
+### Beispiel Factory Pattern
+- **Logistik Management Anwendung**
+- Erste Version kann nur mit LKWs transportieren
+- Transportation mit Schiff kommt dazu
+  - Code aus LKW Klasse muss teilweise auch in Schiffklasse verwendet werden
+  - Vllt. kommen ja noch mehr Transportmittel dazu?
+- **Lösung**
+  - ![image_377.png](image_377.png)
+  - Objektkreation macht nur die Factory-Methode, spezifisch für das Produkt
+    - In diesem Fall Transport
+  - Logistics ist der Ersteller
+    - Plan für die Lieferung
+    - Definierung der FactoryMethode
+  - ConcreteCreators
+    - ![image_378.png](image_378.png)
+
+### Fazit Factory Method
+- Implementierung von OO Prinzipien
+  - [OCP](SOLID-Principle.md#o-open-closed-principle-ocp)
+    - Motivierung ist, dass Applikation erweiterbar ist
+    - Client bleibt geschlossen
+  - [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp)
+    - Kann gestört werden durch unterdrückung der Standardimplementierung durch eine Subklasse
+  - [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip)
+    - Client definiert/besitzt Interface für Ersteller und Produkte
+- Bestärkt [Loose Coupling](ImplementingForMaintainability.md#loose-coupling)
+
+
+## Abstract Factory
+- Interface für die Erstellung von Familien oder Abhängigkeiten von Objekten
+
+### Struktur Abstract Factory
+![image_379.png](image_379.png)
+#### AbstractFactory (Interface)
+- Deklariert Interface fpr Operationen, die Objekte produzieren
+
+#### ConcreteFactory
+- Repräsentiert Factory für eine Variante/Familie von Produkten
+- Implementiert die Operationen, um Objekte zu erstellen
+
+#### AbstractProduct (Interface)
+- Deklariert Interface für einen Typ
+
+#### ConcreteProduct
+- Definiert konkretes Produkt der Familie
+
+#### Client
+- Nutzt nur AbstractFactory und AbstractProduct
+
+### Beispiel Abstract Factory
+- ![image_380.png](image_380.png)
+- AbstractProduct
+  - Chair, Sofa, CoffeeTable
+- Produkt
+  - 3 jeder abstrakten Klasse
+- Abstract Factory
+  - Interface für FurnitureFactory
+- ConcreteFactory
+  - Implementierung des AbstractFactory Interface
+
+### Fazit Abstract Factory
+- **OO Prinzipien**
+  - [OCP](SOLID-Principle.md#o-open-closed-principle-ocp)
+  - [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp)
+    - Abhängig von der Implementierung
+  - [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip)
+    - Client definiert/besitzt Interface für Ersteller und Produkte
+
+
+## Singleton 
+- Sorgt dafür, dass eine Klasse nur ein Interface hat und dieses global erreichbar ist
+- Wird genutzt, wenn eine Klasse nur eine einzelne Instanz haben soll
+  - bspw. DatenbankVerbindung
+
+### Struktur Singleton
+- Konstruktor hat private Sichtbarkeit
+  - Methode getInstance()
+    - ![image_381.png](image_381.png)
+
+### Beispiel Singleton
+- ![image_382.png](image_382.png)
+
+### Fazit Singleton
+- **Probleme**
+  - Pattern löst zwei Probleme gleichzeitig 
+    - verletzt [SRP](SOLID-Principle.md#s-single-responsibility-principle-srp)
+  - Kann schlechtes Design verstecken (bspw. kein Loose Coupling)
+
+
+## Adapter Pattern
 -