Builder (Design Pattern): Unterschied zwischen den Versionen

Aus Byte-Welt Wiki
Zur Navigation springenZur Suche springen
 
K (1 Versionen)
(kein Unterschied)

Version vom 13. Juni 2007, 17:02 Uhr

Der Builder, im Deutschen auch Erbauer genannt, ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zur Kategorie der Creational Pattern (Erzeugungsmuster). Das Muster ist eines der sogenannten GoF-Muster.

Zweck

Es trennt die Konstruktion eines komplexen Objektes von dessen Repräsentation. Dadurch kann derselbe Konstruktionsprozess verschiedene Repräsentationen erzeugen.

Motivation

Entwickler verwenden den Builder, wenn

  • zu einem komplexen Objekt unterschiedliche Repräsentationen existieren sollen; oder
  • wenn die Konstruktion eines komplexen Objekts unabhängig von der Erzeugung der Bestandteile sein soll; oder
  • wenn der Konstruktionsablauf einen internen Zustand erfordert, den man vor einem Klienten verbergen möchte.

Typische Anwendungen sind z.B. Applikationen zur Konvertierung.

Struktur

Teilnehmer

  • Builder
    • spezifiziert eine abstrakte Schnittstelle zur Erzeugung der Teile eines komplexen Objektes
  • KonkreterBuilder
    • erzeugt die Teile des komplexen Objekts durch Implementation der Schnittstelle
    • definiert und verwaltet die von ihm erzeugte Repräsentation des Produkts (hat also internen Zustand)
    • bietet Schnittstelle zum Auslesen des Produkts
  • Direktor
    • konstruiert ein komplexes Objekt unter Verwendung der Builder-Schnittstelle. Der Direktor arbeitet eng mit dem Builder zusammen: Er weiß, welche Baureihenfolge der Builder verträgt (z.B. müssen in einem Baum zuerst Blätter, dann innere Knoten erzeugt werden; oder umgekehrt). Daher ist eine weitere Verantwortung des Direktors:
    • Entkopplung des Konstruktionsablaufs vom Klient.
  • Produkt
    • repräsentiert das zu konstruierende komplexe Objekt
    • beinhaltet Klassen zur Definition der einzelnen Teile

Interaktion

Konsequenzen

Vorteile

  • Die Implementationen der Konstruktion und der Repräsentationen werden isoliert.
  • Builder verstecken ihre interne Repräsentation vor dem Direktor.
  • Neue Repräsentationen lassen sich leicht durch neue konkrete Builderklassen einfügen.
  • Der Konstruktionsprozess wird an einer dedizierten Stelle (im Direktor) gesteuert; spätere Änderungen - etwa ein Mehrphasen-Konstruktionsprozess statt einer Einphasen-Konstruktion - lassen sich ohne Änderung der Klienten realisieren.

Nachteile

  • Der Konstruktion der Objekte erfordert oft Wissen über die Verwendung und Umgebung der Objekte.


Implementierung/Beispielcode

  • Ein Automobil besteht aus Rädern, Motor und Karosserie. Die Bestandteile liegen als verschiedene Klassen vor (z.B. schwacher und starker Motor). Der Direktor konstruiert ein Fahrzeug, indem er eine der konkreten Builderklassen Geländewagen oder Limousine erhält und dort die Methoden zum Bauen der Teile in der (für den Builder) richtigen Reihenfolge aufruft. Beide Klassen erben von der Builderklasse Fahrzeug. Der Direktor stellt ein Produkt her, indem er die Buildermethoden baueRäder(), baueKarosserie() und baueMotor() aufruft. Limousine erzeugt ein Teile für ein Auto, das aus normalen Rädern, Limousinenkarosserie und schwachem Motor besteht. Der Geländewagen setzt sich aus off-road Rädern, höhergelegter Karosserie und starkem Motor zusammen. Braucht der Entwickler ein Cabriolet, schreibt er einen konkreten Builder Cabriolet für Cabrioletteile.
  • Java: java.text.StringBuffer, java.io.Writer
  • .Net: System.Text.StringBuilder, System.IO.StreamWriter

In den Java- und .Net-Beispielen kann der Klient der Direktor sein. Eine Entkopplung, z.B. über eine Methode Factory, ist aber zu empfehlen.

Variantionen

Man kann auch das Produkt selber die Builder-Schnittstelle implementieren lassen.

  • Vorteil: Dadurch erspart man sich u.U. einige Klassen.
  • Konsequenz: Das erzeugte Produkt "schleppt" die Builder-Schnittstelle sein ganzes Leben mit sich herum, sodass auch später von außen Produktteile angebaut werden können.


Bekannte Verwendungen

Dieses Muster wird in der Software-Analyse wegen der schwierigen Metapher selten verwendet.

Die Variante allerdings, wo ein Objekt selbst Verfahren zur Verfügung stellt, um weitere Teile "anzubauen", bewährt sich in pipeline-artigen Business-Prozessen. Der Business-Prozess als Direktor weist das Dokument als Builder an, neue Teile zu erzeugen und in sich einzuhängen. Z.B. kann ein Aktenverwaltung in einzelnen Schritten Vermerke an einen "Aktenlauf" anhängen.

Verwandte Muster

  • Die Abstract Factory ähnelt dem Builder, weil sie ebenfalls komplexe Objekte erzeugen kann. Dabei steht aber nicht die Struktur im Vordergrund, sondern die Abstraktion vom konkreten Typ der erzeugten Objekte.
  • Der Builder erzeugt oft ein Composite.
  • Bei Applikationen zur Konvertierung ist der Direktor - oder sogar der Builder - oft ein Visitor oder eventuell ein Interpreter der Struktur, die konvertiert werden soll.
Dieser Beitrag stammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Er ist dort unter Erbauer zu finden, die Liste der bisherigen Autoren befindet sich in der Versionsliste.