Differences

This shows you the differences between two versions of the page.

--- design_patterns [2025/06/27 20:16]
172.19.0.1 old revision restored (2024/10/12 04:21)
+++ design_patterns [2025/07/03 10:35] (current)
172.19.0.1 old revision restored (2025/07/01 01:11)
@@ Line 1: / Line 1: @@
+====== Design Patterns ======
+**//Ein Muster//** ist eine Lösung eines Problems in einem bestimmten Kontext.
+  * Der **Kontext** ist die Situation, in der das Muster angewendet wird. Es sollte eine wiederkehrende Situation sein
+  * Das **Problem** umfasst das Ziel, das Sie in diesem Kontext erreichen möchten, aber auch alle Einschränkungen (oder Randbedingungen), die in dem Kontext auftreten können.
+  * Die **Lösung** ist das, was Sie gern hätten: Ein allgemeiner Entwurf, mit dem jeder das Ziel erreichen und diesen Satz von Einschränkungen überwinden kann.
+**//Merkspruch://** Wenn Sie in einem bestimmten Kontext einem Problem gegenüberstehen und das Erreichen des Ziels nur mit gewissen Einschränkungen möglich ist, können Sie ein Muster anwenden, das zu einer Lösung für dieses Ziel und die zugehörigen Einschränkungen führt.
+Musterkategorien:
+**//Erzeugungsmuster//** beinhalten die Instantiierung von Objekten: sie alle bieten einen Weg, einen Client von den Objekten zu entkoppeln, die er instantiieren muss.
+  * Singleton
+  * Builder
+  * Prototype
+  * Factory Method
+  * Abstract Factory
+**//Verhaltensmuster//** haben all damit zu tun, wie Klassen und Objekte miteinander in Wechselwirkung stehen und die Zuständigkeiten untereinander aufteilen.
+  * Mediator
+  * Visitor
+  * Template Method
+  * Iterator
+  * Command
+  * Memento
+  * Interpreter
+  * Observer
+  * Chain of Responsibility
+  * State
+  * Strategy
+**//Strukturmuster//** ermöglichen die Zusammensetzung von Klassen oder Objekten zu größeren Strukturen.
+  * Proxy
+  * Decorator
+  * Composite
+  * Facade
+  * Flyweigth
+  * Bridge
+  * Adapter
+**//Decorator//**\\
+Packt ein Objekt ein und fügt dabei neues Verhalten hinzu
+**//State//**\\
+Kapselt zustandsbasiertes Verhalten und wechselt durch Delegieren zwischen den Verhaltensweisen.
+**//Iterator//**\\
+Bietet eine Möglichkeit, eine Sammlung von Objekten zu durchqueren, ohne die Implementierung der Sammlung zu offenbaren.
+**//Facade//**\\
+Vereinfacht die Schnittstelle für eine Gruppe von Klassen.
+**//Strategy//**\\
+Kapselt austauschbares Verhalten und entscheidet mittels Delegierung, welches Verhalten verwendet wird.
+**//Proxy//**\\
+Umschließt ein Objekt und kontrolliert so den Zugriff darauf
+**//Factory Method//**\\
+Unterklassen entscheiden, welche konkreten Klassen erzeugt werden.
+**//Adapter//**\\
+Umschließt ein Objekt und stellt eine andere Schnittstelle dafür zur Verfügung.
+**//Observer//**\\
+Ermöglicht die Benachrichtigung von Objekten, wenn sich eine Zustand ändert.
+**//Template Method//**\\
+Unterklassen entscheide, wie die Schritte ein einem Algorithmus implementiert werden.
+**//Composite//**\\
+Clients behandeln Sammlungen von Objekten und Einzelobjekten auf gleiche Weise.
+**//Singleton//**\\
+Sorgt dafür, dass nur genau ein Objekt erzeugt wird.
+**//Abstract Factory//**\\
+Ermöglicht des einem Client, Familien von Objekten zu erstellen, ohne konkrete Klassen anzugeben.
+**//Command//**\\
+Kapselt einen Auftrag als in Objekt.
+Punkt für Punkt:
+  * Verwenden Sie Muster in Ihren Entwürfen nur dann, wenn es sich auf natürliche Weise ergibt, und nicht zwangsweise, nur um ein Muster zu benutzen.
+  * Entwurfsmuster sind nicht in Stein gemeißelt; Sie können sie so anpassen und zurecht biegen, wie Sie sie gerade brauchen.
+  * Verwenden Sie immer die einfachste Lösung, die Ihren Anforderungen entspricht, selbst wen sie kein Muster umfasst.
+  * Studieren Sie Musterkataloge, um sich mit Mustern und den Beziehungen zwischen Ihnen vertraut zu machen.
+  * Mit Musterklassifikationen (oder -kategorien) lassen sich Muster in Gruppen einteilen. Wenn es Ihnen weiterhilft, benutzen Sie sie.
+  * Um selbst Muster zu schreiben, müssen Sie viel Engagement, Zeit und Geduld mitbringen, und Sie müssen bereit sein, eine Menge Code-Verbesserungen durchzuführen.
+  * Denken Sie daran, dass die meisten Muster, denen Sie begegnen werden, Anpassungen existierender Muster sind und keine neuen Muster.
+  * Erweitern Sie das gemeinsame Vokabular in Ihrem Team - einer der größten Vorteile, die Sie aus der Verwendung von Mustern ziehen können.
+  * Wie jede Gemeinschaft hat auch die Mustergemeinde ihren eigenen Fachjargon. Lassen Sie sich davon nicht abschrecken.
 ===== OO-Basics =====
@@ Line 6: / Line 99: @@
   * Inheritance
+===== OO-Principles =====
+  * Kapseln Sie das, was variiert.
+  * Ziehen Sie die Komposition der Vererbung vor.
+  * Programmieren Sie auf ein Schnittstelle, nicht auf eine Implementierung.
+  * Streben Sie für Objekte, die interagieren, nach Entwürfen mit lockere Bindung.
+  * Klassen sollten für Erweiterung offen, aber für Veränderung geschlossen sein.
+  * Stützen Sie sich auf Abstraktionen. Stützen Sie sich nicht auf konkrete Klassen (Dependency Inversion Principle).
+  * Sprechen Sie nur mit Ihren engsten Freunden (Prinzip der Verschwiegenheit).
+  * Versuchen Sie nicht, uns anzurufen, wir rufen Sie an (Hollywood-Prinzip).
+  * Eine Klasse sollte nur einen Grund haben, sich zu ändern.
+Dependency Inversion Principle - Policies:
+  * Keine Variable sollte eine Referenz auf eine konkrete Klasse halten. Wenn Sie **new** verwenden, halten Sie eine Referenz auf eine konkrete Klasse.Verwenden Sie eine Factory, um das zu umgehen.
+  * Keine Klasse sollte von einer konkreten Klasse abgeleitet sein. Wenn Sie von einer konkreten Klasse ableiten, sind Sie von einer konkreten Klasse abhängig. Leiten Sie von einer Abstraktion wie einem Interface oder einer abstrakten Klasse ab.
+  * Keine Methode sollte eine implementierte Methode einer ihrer Basisklassen überschreiben. Wenn Sie eine implementierte Methode überschreiben, war Ihre Basisklasse keine Abstraktion, die als Ausgangspunkt tauglich ist. Zweck der in der Basisklasse implementierten Methoden ist, dass sie von allen Ihren Unterklassen geteilt werden.
+Das Prinzip der Verschwiegenheit - Policies:
+  * Jede Methode eines Objektes sollte nur Methoden aufrufen, die zum Objekt selbst,
+  * zu Objekten, die der Methode als Parameter übergeben wurde,
+  * zu Objekten, die die Methode erstellt oder instantiiert, sowie
+  * zu Komponenten des Objekts gehören.
 ===== OO-Patterns =====

DokuWiki

Site Tools

Differences

Page Tools