Generative Designmuster - Builder

Builder, шаблоны проектирования, Строитель

Die Gründe

• Trennen der Konstruktion eines komplexen Objekts von seiner Repräsentation, sodass derselbe Konstruktionsprozess unterschiedliche Repräsentationen erzeugen kann.
• Zerlegen einer komplexen Darstellung, Erstellen eines Ziels aus mehreren Varianten.

Probleme

Trennung des Objektinterpretationsalgorithmus (z. B. Dokumentenparsing) vom Mechanismus zum Speichern des Bereitschaftszustands des Objekts. Beispielsweise das Erstellen eines komplexeren oder anderen Zielobjekts aus einer RTF-Datei, z. B. ASCII-Text, TeX, ein Text-Widget. Der Fokus liegt auf der Erstellung komplexer Aggregate.

Der „Director“ ruft den „Builder“-Dienst auf, weil er das externe Format interpretiert. Der „Builder“ erstellt bei jedem Aufruf einen Teil des komplexen Objekts und hält alle Zwischenstände aufrecht. Wenn das Produkt fertiggestellt ist, erhält der Kunde das Ergebnis vom „Builder“.

Bietet eine genauere Kontrolle über den Konstruktionsprozess eines Objekts. Im Gegensatz zu Erstellungsmustern, die Produkte in einem einzigen Aufruf erstellen, erstellt das Builder-Muster ein Produkt sequentiell unter der Kontrolle eines "Directors".

Struktur

Reader kapselt das Parsen von Eingabeinformationen. Und der Builder ermöglicht die polymorphe Erstellung vieler einzigartiger Ansichten oder Ziele.

Beispiel

Das Builder-Muster trennt die Konstruktion eines komplexen Objekts von seiner Repräsentation, sodass derselbe Konstruktionsprozess unterschiedliche Repräsentationen erzeugen kann. Nehmen wir als Beispiel ein Kinderrestaurant. In diesem Fall wird diese Vorlage wie folgt verwendet. Babynahrung besteht normalerweise aus einem Hauptartikel, einem Artikel, einem Getränk und einem Spielzeug (z. B. einem Hamburger, einer Kartoffel, einer Cola und einem Spielzeugdinosaurier). Bitte beachten Sie, dass sich der Inhalt der Babynahrung ändern kann, der Herstellungsprozess jedoch gleich bleibt. Ob der Kunde einen Hamburger, Cheeseburger oder Hähnchen bestellt, der Prozess ist derselbe. Der Mitarbeiter an der Theke erteilt den Auftrag zur Abholung des Hauptartikels, des Beipackzettels und des Spielzeugs. Diese Gegenstände werden dann in eine Tasche gelegt. Das Getränk wird in einen Becher gefüllt und hinter der Tüte zurückgelassen. Dasselbe Verfahren wird in anderen Restaurants verwendet.

Kontrollliste

• Entscheiden Sie, ob das Problem ein Problem mit einer gemeinsamen Dateneingabe und mehreren möglichen Ansichten (oder Ausgaben) ist.
• Kapseln Sie das Parsen der gemeinsamen Eingabe in einer Reader-Klasse.
• Erstellen Sie ein Standardprotokoll zum Erstellen aller möglichen Ausgabedarstellungen. Erfassen Sie die Schritte dieses Protokolls in Interface Builder.
• Definieren Sie eine vom Builder abgeleitete Klasse für jede Zielansicht.
• Der Client erstellt ein Reader-Objekt und ein Builder-Objekt und registriert letzteres bei ersterem.
• Der Client fordert den Reader auf, zu "bauen".
• Der Client bittet den Builder, ein Ergebnis zurückzugeben.

Faustregeln

• Manchmal ergänzen sich die Erstellungsmuster: Der Builder kann eines der anderen Muster verwenden, um die zu erstellenden Komponenten zu implementieren. Abstract Factory, Builder und Prototype können Singleton in ihren Implementierungen verwenden.
• Builder konzentriert sich darauf, ein komplexes Objekt Schritt für Schritt zu erstellen. Eine abstrakte Fabrik betont eine Familie von Objekten (einfach oder komplex). Der Builder gibt das Produkt als letzten Schritt zurück, aber was die abstrakte Fabrik betrifft, kehrt das Produkt sofort zurück.
• Builder erstellt oft ein Composite.
• Oft beginnen Projekte mit der Factory-Methode (weniger komplex, anpassbar, Unterklassen nehmen zu) und entwickeln sich zu Abstract Factory, Prototype oder Builder (flexibler, komplexer), wenn der Entwickler feststellt, dass mehr Flexibilität erforderlich ist.