Differences

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

--- design_patterns [2025/07/01 01:11]
172.19.0.1 old revision restored (2025/05/21 23:13)
+++ design_patterns [2025/07/01 18:43] (current)
172.19.0.1 old revision restored (2024/03/09 09:08)
@@ 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 99: / Line 6: @@
   * 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 =====
@@ Line 147: / Line 34: @@
   * Verlassen Sie sich nicht auf eine bestimmte Reihenfolge der Benachrichtigung Ihrer Beobachter.
-==== Decorator ====
-Fügt einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu. Dekorierer bieten eine flexible Alternative zur Ableitung von Unterklassen zum Zweck der Erweiterung der Funktionalität.
-Punkt für Punkt:
-  * Vererbung ist eine Form von Erweiterung, aber nicht notwendigerweise der beste Weg, um Ihren Entwürfen Flexibilität zu verleihen.
-  * Unsere Entwürfe sollten die Erweiterung von Verhalten ermöglichen, ohne dass dazu bestehender Code geändert werden müsste.
-  * Oft können Komposition und Delegierung verwendet werden, um zur Laufzeit neue Verhalten hinzuzufügen.
-  * Für die Erweiterung von Verhalten bietet das Decorator-Muster eine Alternative zur Ableitung von Unterklassen.
-  * Das Decorator-Muster schließt einen Satz von Dekorierer-Klassen ein, die verwendet werden, um konkrete Komponenten einzupacken.
-  * Dekorierer-Klassen spiegeln den Typ der Komponente wider, die sie dekorieren. (Sie haben tatsächlich den gleichen Typ wie die Komponente, die sie dekorieren, entweder durch Vererbung oder durch die Implementierung eines Interface.)
-  * Dekorierer ändern das Verhalten der Komponente, indem sie vor und/oder nach (oder auch an Stelle von) Methodenaufrufen auf der Komponente neue Funktionalitäten hinzufügen.
-  * Sie können eine Komponente mit einer beliebigen Zahl von Dekorierern einpacken.
-  * Dekorierer sind für die Clients der Komponente überlichweise transparent, außer wenn sich der Client auf den konkreten Type der Komponente stützt.
-  * Dekorierer können in Ihren Entwürfen zu vielen kleinen Objekten führen, und eine übermäßige Verwendung kann den Code unübersichtlich machen.
 ==== Factory ====
@@ Line 197: / Line 70: @@
   * Befehle können auch verwendet werden, um Loggings und Transaktionsysteme zu implementieren.
-==== Adapter, Facade ====
-**//Adapter//**
-Das Adapter-Muster konvertiert die Schnittstelle einer Klasse in die Schnittstelle, die der Client erwartet. Adapter ermöglichen die Zusammenarbeit von Klassen, die ohne nicht zusammenarbeiten könnten, weil sie inkompatible Schnittstellen haben.
-**//Facade//**
-Das Facade-Muster bietet eine vereinheitliche Schnittstelle für einen Satz von Schnittstellen eines Basissystems. Die Fassade definiert eine hochstufigere Schnittstelle, die die Verwendung des Basissystems vereinfacht.
-Punkt für Punkt:
-  * Nehmen Sie Adapter, wenn Sie eine bestehende Klasse verwenden müssen und ihre Schnittstelle nicht der entspricht, die Sie benötigen.
-  * Verwenden Sie Facade, wenn Sie eine größere Schnittstelle oder eine komplexe Menge von Schnittstellen vereinfachen müssen.
-  * Ein Adapter ändert eine Schnittstelle in die, die ein Client erwartet.
-  * Eine Fassade entkoppelt eine Client von einem komplexen Basissystem.
-  * Je nach Größe und Komplexität einer Ziel-Schnittstelle kann es etwas Arbeit sein, einen Adapter zu implementieren.
-  * Bei der Implementierung einer Fassade ist es erforderlich, dass man die Fassade mit ihrem Basissystems zusammensetzt und Delegierung verwendet, um die Arbeit der Fassade durchzuführen.
-  * Es gibt zwei Formen des Adapter-Musters: Objekt- und Klassen-Adapter. Für Klassen-Adapter ist Mehrfachvererbung erforderlich.
-  * Für ein Basissystem können Sie mehr als eine Fassade implementieren.
-  * Ein Adapter umhüllt ein Objekt, um seine Schnittstelle zu ändern, ein Dekorierer umhüllt ein Objekt, um neue Verhalten und Verantwortlichkeiten hinzuzufügen, eine Fassade umhüllt einen Satz von Objekten, um die Schnittstelle zu vereinfachen.
 ==== Template Method ====
@@ Line 268: / Line 121: @@
   * Model 2 ist ein Anpassung des MVC für Webanwendungen.
   * Im  Model 2 ist der Controller als Servlet implementiert und der View als JSP & HTML.
-===== Links =====
-  * [[http://www.namespace-cpp.de/std/doku.php/kennen/begriffe#dokuwiki__top|Begriffe aus C++ und OO]]
-  * [[http://hillside.net/europlop/HillsideEurope|Hillside Group]]
-  * [[http://c2.com|Cunningham & Cunningham]]
-  * [[http://c2.com/ppr|Portland Pattern Repository]]
-  * [[http://wiki.c2.com/?CategoryPattern|C2 Pattern Catalog]]
-  * [[http://wiki.c2.com/?AntiPatternsCatalog|C2 Anit Patterns Catalog]]

DokuWiki

Site Tools

Differences

Page Tools