Erbauer

Der Erbauer (engl. Builder) ist ein Erzeugungsmuster (Creational Patterns). Es trennt die Konstruktion komplexer Objekte von deren Repräsentationen, wodurch die selben Konstruktionsprozesse wiederverwendet werden können.

Verwendung

Entwickler verwenden den Erbauer, wenn

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

Typische Anwendungen sind z.B. Applikationen zur Konvertierung.

UML-Diagramm

Akteure

Erbauer
- spezifiziert eine abstrakte Schnittstelle zur Erzeugung der Teile eines komplexen Objektes
KonkreterErbauer
- 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 Erbauer-Schnittstelle. Der Direktor arbeitet eng mit dem Erbauer zusammen: Er weiß, welche Baureihenfolge der Erbauer 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

Vorteile

Die Implementationen der Konstruktion und der Repräsentationen werden isoliert.
Erbauer verstecken ihre interne Repräsentation vor dem Direktor.
Neue Repräsentationen lassen sich leicht durch neue konkrete Erbauerklassen 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.

Variante

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

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

Verwendung in der Analyse

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 Erbauer an, neue Teile zu erzeugen und in sich einzuhängen. Z.B. kann ein Aktenverwaltung in einzelnen Schritten Vermerke an einen "Aktenlauf" anhängen.

Beispiele

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 Erbauerklassen Geländewagen oder Limousine erhält und dort die Methoden zum Bauen der Teile in der (für den Erbauer) richtigen Reihenfolge aufruft. Beide Klassen erben von der Erbauerklasse Fahrzeug. Der Direktor stellt ein Produkt her, indem er die Erbauermethoden 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 Erbauer 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 Klassenfabrik, ist aber zu empfehlen.

Muster: Builder