278 lines
10 KiB
Markdown
278 lines
10 KiB
Markdown
# 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
|
|
|
|
## Pattern - SOLID
|
|
|
|
| | Factory | Singleton | Composite | Adapter | Facade | Observer | Strategy | State |
|
|
|-----------------------------------------------------------------|---------------------------------------------------------------|-----------|---------------------------|--------------------------------|-----------------------------|----------|----------|-------|
|
|
| [Srp](SOLID-Principle.md#s-single-responsibility-principle-srp) | X <br/>viele unterschiedliche Creator, die eine Aufgabe haben | - | ? <br/>(sowohl als auch) | x | X<br/>mit Tendenz zu ? | X | | |
|
|
| [Ocp](SOLID-Principle.md#o-open-closed-principle-ocp) | X | - | X | x | - <br/>zumindest in Vorlage | X | | |
|
|
| [Lsp](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp) | ? | - | ? <br/>(kann, muss nicht) | - | - | X | | |
|
|
| [Isp](SOLID-Principle.md#i-interface-segregation-principle-isp) | ?/X | - | - | X<br/>sollte, kann aber auch ? | - <br/>zumindest in Vorlage | X | | |
|
|
| [Dip](SOLID-Principle.md#d-dependency-inversion-principle-dip) | X | - | X | X | - <br/>zumindest in Vorlage | ? | | |
|
|
|
|
### Legend
|
|
- **X**: follows clearly
|
|
- **?**: not sure, might follow / changes with implementation
|
|
- **-**: has nothing to do with it
|
|
|
|
## 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
|
|
- 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
|
|
|
|
#### 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
|
|
|
|
#### 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**
|
|
- 
|
|
- 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
|
|
- 
|
|
|
|
### 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
|
|
|
|
#### 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
|
|
- 
|
|
- 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()
|
|
- 
|
|
|
|
### Beispiel Singleton
|
|
- 
|
|
|
|
### Fazit Singleton
|
|
- **Probleme**
|
|
- Pattern löst zwei Probleme gleichzeitig
|
|
- verletzt [SRP](SOLID-Principle.md#s-single-responsibility-principle-srp)
|
|
- Kann sychlechtes Design verstecken (bspw. kein Loose Coupling)
|
|
|
|
|
|
## Adapter Pattern
|
|
- Erlaubt das Nutzen eines Clients mit einem inkompatiblen Interface
|
|
|
|
### Structure Adapter Pattern
|
|
|
|
#### Target
|
|
- Definiert domänenspezifisches Interface, das der Client nutzt
|
|
|
|
#### Client (Adapter Pattern)
|
|
- Arbeitet mit Objekten, welche mit dem [Target](#target)-Interace übereinstimmen
|
|
|
|
#### Adaptee
|
|
- Definiert existierendes Interface, welches Adaption benötigt
|
|
|
|
#### Adapter
|
|
- Adaptiert das Interface des Adaptee zum Target-Interface
|
|
|
|
#### Collaborations
|
|
- Client ruft Operationen auf dem Adapter-Interface auf
|
|
|
|
### Beispiel Adapter Pattern
|
|
|
|
|
|
|
|
### Fazit Adapter Pattern
|
|
- **SRP**
|
|
- Primäre Business Logik eines Programms ist vom Interface getrennt
|
|
- **OCP**
|
|
- Neuer Adapter kann, ohne den existierenden Code zu bearbeiten, erstellt werden
|
|
|
|
- Adapter ändert Interface in eins, das der Client erwartet
|
|
- **Sollte vermieden werden, wenn es möglich ist**
|
|
|
|
|
|
## Facade Pattern
|
|
- Klasse, die ein simples Interface zu einem komplexen System bereitstellt
|
|
|
|
### Struture Facade Pattern
|
|
|
|
#### Facade
|
|
- Weiß, welche Subsystem-Klassen verantwortlich sind
|
|
- Delegiert Client-Anfragen an Klassen
|
|
|
|
#### Subsystem Classes
|
|
- Implementiert Subsystem Funktionalität
|
|
- Hat kein Wissen von der Fassade
|
|
|
|
#### Collaborations Facade Pattern
|
|
- Clients kommunizieren mit dem Subsystem durch requests zur Fassade
|
|
|
|
### Fazit Facade Pattern
|
|
- **SRP**
|
|
- Kann verletzt werden je nach Implementierung
|
|
|
|
## Composite Pattern
|
|
- Baumartige Objektstruktur
|
|
### Structure Composite Pattern
|
|
|
|
|
|
#### Component (Abstract Class)
|
|
- Deklariert Interface für Objekte in der Komposition
|
|
- Implementiert für teilweises default-Verhalten
|
|
|
|
#### Leaf
|
|
- Definiert Verhalten, welches individuell für die Klasse ist
|
|
|
|
#### Composite
|
|
- Definiert Verhalten für Branch-Komponenten
|
|
|
|
#### Client (Composite Pattern)
|
|
- Nutzt Objekte in der Komposition durch das Interface
|
|
|
|
### Beispiel Composite Pattern
|
|
|
|
|
|
|
|
## Strategy Pattern
|
|
|
|
|
|
## State Pattern
|
|
|
|
|