Java builder Pattern?

1 Antwort

Ich kann dir nicht wirklich beantworten, was die da haben wollen, aber ein paar Anmerkungen:

1) Da es idR nur noch einen Konstruktor mit der Builder-Klasse als Argument gibt, erzwingt man die Erstellung über den Builder. Der Konstruktor selbst ist aber public. Man könnte theoretisch auch weitere Konstruktoren ohne die Builder-Klasse anlegen, oft ist das aber nicht sinnvoll, weil man im build() des Builders gf. zulässige Attributkombinationen checken will.

2) Im Prinzip ersetzt man damit die named paramters bei anderen Programmiersprachen, indem man halt statt einem langem Konstruktor mit vielen positional Parametern eine "sprechende" Darstellung hat. Das hilft sicher auch, Fehler zu vermeiden, wenn man halt statt new Foo(1,2,3) dann new Foo.builder().setX(1).setY(2).setZ(3) schreibt. Daher würde ich sagen, ja. Sinn macht es vor allem, wenn man optionale Parameter hat, wo man in Java entweder viele Konstruktoren oder aber eine ziemlichen Krampf Object... a o.ä. braucht.

3) Schwierig. Für neue Funktionalität muss man nicht unbedingt den Konstruktor ändern, das braucht man nur, wenn man schon beim Erzeugen der Klasse neue Attribute hinzufügen muss. Wenn man neue Attribute braucht, ist das mit einem Builder einfacher als den Konstruktor zu ändern, sind die neuen Attribute allerdings verpflichtend, schiebt man hier die Prüfung von der Erstellungszeit auf die Laufzeit, was es ggf. eher schlimmer macht. Man sieht der Schnittstelle einer Klasse nicht mehr an, welche Attribute gesetzt sein müssen.

4) Würde ich ankreuzen. Siehe 2). Und man kann halt im Builder die gesetzten Attribute ggf. auch prüfen und da eine Exception bei ungültiger Kombination werfen.

Baut man Setter der Klasse ohne Builder so, dass Sie das Objekt zurückgeben, so dass man die Attribute die bei 2) angegeben auch nacheinander setzen kann, hat das leider den Nachteil, das dies nicht Thread-safe ist und ggf. unvorhersehbare Effekte mitbringt.

Woher ich das weiß:Berufserfahrung – Softwareentwickler & Admin