Swerflash: 1 Versionen

2007-06-13T17:02:27Z

1 Versionen

← Nächstältere Version	Version vom 13. Juni 2007, 17:02 Uhr
(kein Unterschied)

EagleEye am 27. Februar 2007 um 18:13 Uhr

2007-02-27T18:13:12Z

Neue Seite

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

__TOC__

== Zweck ==
Es trennt die [[Konstruktion]] eines komplexen [[Objekt]]es 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. [[Anwendungsprogramm|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 (Design Pattern) | 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 (Design Pattern) | 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 (Design Pattern) | Composite]].
* Bei Applikationen zur Konvertierung ist der Direktor - oder sogar der Builder - oft ein [[Visitor (Design Pattern) | Visitor]] oder eventuell ein [[Interpreter (Design Pattern) | Interpreter]] der Struktur, die konvertiert werden soll.

[[Kategorie:Design Pattern]]
[[Kategorie:Creational Pattern]]
[[Kategorie:Gang of Four Pattern]]
{{Wikipedia|Seite=Erbauer}}

Builder (Design Pattern) - Versionsgeschichte

Swerflash: 1 Versionen

EagleEye am 27. Februar 2007 um 18:13 Uhr