Diskussion:Erbauer (Entwurfsmuster)

message: Im UML Diagramm ist eine Aggregation zwischen Direktor und Erbauer dargestellt. Wenn aber, wie ich vermute, der Direktor das Erzeugen des Objektes an den Erbauer deligiert, muss eine Komposition verwendet werden.
:Es muss keine Komposition verwendet werden, es kann aber eine, oder auch einfach nur eine Assoziation. Ich glaube, der Aggregationspfeil ist ein Überbleibsel aus dem GoF-Buch, in dem an dieser Stelle auch ein Aggregationspfeil eingezeichnet sit. Sinnvoller ist aber in der Tat eine Assoziation. Um das Produkt zu bauen, muss der Direktor ja nur den Erbauer kennen, ihn nicht "im Bauch" habe, also selbst erzeugen. Wenn ich Zeit habe, werde ich das Bild entsprechend ändern. --Wikiplex 17:17, 25. Aug. 2009 (CEST)
thread_title:  UML Diagramm, besser Komposition 

message: Ich finde das momentane C++ Beispiel trifft nicht so richtig den Gedanken hinter dem Muster. Ich habe meinen Vorschlag eingereicht: https://de.wikipedia.org/w/index.php?title=Erbauer_(Entwurfsmuster)&oldid=126871205
--Sebmes (Diskussion) 10:02, 26. Jan. 2014 (CET)
replies: text: Ich denke auch, dass dein Beispiel besser sein könnte als das C++ Beispiel (hab es aber gelöscht, da sonst 2 Beispiele). Möchte zu deinem Beispiel aber noch folgende Überlegungen anbringen: 1) der konkrete Builder sollte nicht nur die Attribute sammeln, sondern das Ding als gesamtes zurückgeben können (wenn es fertig gebaut ist) - siehe "getResult" Methode in der Grafik. d.h. dein Interface sollte keine getter haben, dein ConcreteSmartphoneBuilder eine getConcreteSmartphone() die das (spezifische) Endprodukt (ConcreteSmartphone) zurückgibt. 2) vielleicht verwendest einen spezielleren Namen als "ConcreteSmartphone" - z.B. mach einen AndroidPhoneBuilder, der sicherstellt, dass z.B. alle Android-Smartphones einen Touchscreen haben 3) vielleicht zeigst bei den vielen Konstruktoren auch das Problem, dass Konstruktoren keinen Namen haben, also public Smartphone(double displaySize, String osName, int cpuSpeed) sich nicht von public Smartphone(double displaySize, String osName, int batteryCapacity) unterscheiden lässt. Das könnte man natürlich auch mit Factory Methoden lösen aber ein Builder löst dieses Problem auch. --Sebastian.Dietrich  ✉ 10:27, 26. Jan. 2014 (CET)

text: P.S. Du könntest bei dem Beispiel auch auf Fluent Interface eingehen - d.h. die setter geben den konkreten Builder wieder zurück und in der Main Methode kannst sagen SmartphoneBuilder b2 = new ConcreteSmartphoneBuilder(4).setOperationsystem("iOS").setCpuSpeed(1200).setBatteryCapacity(1440);
--Sebastian.Dietrich  ✉ 10:33, 26. Jan. 2014 (CET)
thread_title:  Alternativvorschlag 

message: Hey *,
schaut man sich den Artikel in der Englischen Wikipedia an findet verständliche Beispiele in diversen Programmiersprachen in einer vernünftigen Länge.
Insbesondere C++ ist in meinen Augen bei weitem nicht so gut lesbar wie eine Java, C#, JavaScript Implementierung.
Nachdem ja auch einige sehr große Libs (StringBuilder in Java) mit dem Builder Pattern ohne Director daherkommen sollte man diese Option nicht außer acht lassen.
Ich würde folgendes Beispiel heranziehen (nachdem das auch in der deutschen Wikipedia gut dokumentiert ist): 
Der Chef de Cuisine ist unser Director (der analog zum Pattern eigentlich auch weiß wie man alles Kocht aber in der Realität eher mit dem zusammensetzen der einzelnen Teile eines Gerichts beschäftigt ist). Dann gibts die Chef de Partie (Saucier, Rôtisseur, usw.) die Kochen Implementationen von Essen die wiederum vom Director zu einem Gericht zusammengesetzt werden. Das sollte das Pattern relativ gut abdecken. Ich würde vorschlagen es in Java zu entwickeln und ganz bewusst auf einige Funktionen verzichten, so dass es dann auch nicht kompilierfähig ist.
Mhupfauer (Diskussion) 09:33, 30. Jan. 2019 (CET)
thread_title:  Zu Kompliziert