Talk:Builder pattern

message: In the diagram, the Builder should be italicized to indicate that it is an Abstract class.  If it is an interface rather than abstract class (alá Java), then it would be better served with an <<interface>> stereotype.  —Preceding unsigned comment added by 71.57.242.240 (talk) 22:06, 12 February 2008 (UTC)
thread_title: Abstract Builder class

message: The Sequence diagram dosen't seems to correspond to the example in Java any toughts ? --Khalid hassani 11:15, 11 August 2006 (UTC)
thread_title: Correspondance between the sequence diagram and the Java program

message: Many people especially beginners are confused about the difference between those two patterns, as they seem very similar, we need to add a section about the difference between the two patterns, the google groups discussion in the External links section seems a good starting point to me.--Khalid hassani 11:19, 11 August 2006 (UTC)
thread_title: Adding a section about the difference between Factory Method pattern and Builder pattern

message: The abstract class PizzaBuilder should not have a protected Pizza data member this should be private.  Having protected data creates fragile class hierarchies and generally should be avoided.  Also a minor point, but generally chefs do the cooking not waiters!
Yeah, I think the Java example should be refactored. Nobnak (talk) 01:58, 3 September 2010 (UTC)
thread_title: Class data members should be private, chefs create pizza

message: The explanation for the Director class is:
"The Director class is responsible for managing the correct sequence of object creation. It receives a Concrete Builder as a parameter and executes the necessary operations on it."
Under the "Difference Between Builder pattern and Abstract factory pattern" heading, this is mentioned:
"...the client just requests a configuration and the builder directs the logic of building it"
This seems to say that the Builder manages "the correct sequence of object creation". Is the client the "Director" or is the builder the "Director"? —The preceding unsigned comment was added by 61.14.96.7 (talk) 07:51, 30 April 2007 (UTC)
replies: text: According to the UML, the client is the Director. And I believe the word "Director" should be replaced with "Client" for clarity and to avoid confusion since some people tend to think "Director"  is a class which is part of the pattern. 186.0.181.64 (talk) 17:46, 10 April 2023 (UTC)
thread_title:  Ambiguity? Or am I just confused... 

message: Previous commentor:  You're not confused.  The author of this article is deeply confused about the Builder pattern.  The sample cited in the first comment above better represents what a Builder is.  —Preceding unsigned comment added by Jdmarshall (talk • contribs) 23:19, 17 December 2007 (UTC)
thread_title:  Missing the Mark 

message: Most of the text for this page is copied directly from http://sourcemaking.com/design_patterns/builder in violation of its license terms.  That work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.  This page does not attribute the work to its original author.
Vaughanje (talk) 19:51, 12 May 2008 (UTC)
thread_title:  Most of this page is copied 

message: The Builder in the class diagram is not an <<interface>>, but it should be (also for the sake of calling the other class ConcreteBuilder). --78.43.87.113 (talk) 14:49, 7 August 2008 (UTC)
thread_title:  Class diagram glitch 

message: The example given leans more towards abstract factory.  As mentioned, Builder is best used for building up Composites.  So, Menu Items in menu system, or Genealogy tree of parents and children.  Builders can use factories, and often do.  This is why the example is confusing.  It is attempting to use factories and be a builder at the same time.  An improvement to the example would be to have a PizzaFactory, a SoftDrinkFactory and SideOrderFactory.  Then, create an OrderBuilder that would build up an order using these factories.  I'm not saying that this is the best example, but much clearer than what is there now.  A simpler example, like building up a MenuSystem for an application, would be much clearer.  —Preceding unsigned comment added by Hosick (talk • contribs) 07:44, 17 May 2009 (UTC)
thread_title:  Example more like Abstract-factory 

message: Gang of Four says not to use abstract functions, but instead use empty functions. Normally on a builder pattern you may not want to implement everything, if you set abstract functions then you'll be forced to implement them, even if it was empty. - 114.76.239.105 (talk) 15:11, 26 December 2010 (UTC)
replies: text: This is getting implementation-specific - placeing requirements on the language of implementation which would prevent the pattern from being universally adopted.  15.203.137.74 (talk) 12:14, 26 November 2014 (UTC)
thread_title:  Abstract functions? 

message: public class BuilderExample {
 	public static void main(String[] args) {
 		Cook cook = new Cook();
 		PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
 		PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder();
  
 		cook.setPizzaBuilder(hawaiianPizzaBuilder);
 		cook.constructPizza();
 
 		Pizza hawaiian = cook.getPizza();
  
 		cook.setPizzaBuilder(spicyPizzaBuilder);
 		cook.constructPizza();
  
 		Pizza spicy = cook.getPizza();
 	}
 }
Wouldn't it be better to do something like the following:
 public class BuilderExample {
 	public static void main(String[] args) {
 		Cook cook = new Cook();
 		PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
 		PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder();
  
 		cook.constructPizza(hawaiianPizzaBuilder);
 		Pizza hawaiian = hawaiianPizzaBuilder.getPizza();
  
 		cook.constructPizza(spicyPizzaBuilder);
 		Pizza spicy = spicyPizzaBuilder.getPizza();
 	}
 }
The Gang of Four have an interaction diagram that shows that you get the resulting product from the builder. I can't see any reason why you would need a setPizzaBuilder setter - you would just pass the pizzaBuilder in as a parameter. This leads to cleaner code, IMO. - FluffySquid (talk) 14:11, 17 January 2011 (UTC)
thread_title:  Is this the best way of doing this? 

message: I'm not sure we need two example implementations. C++ and Java are not radically different in syntax, and there's nothing about the pattern that can't be covered in one. — anndelion ❋ 21:40, 18 April 2011 (UTC)
replies: text: Not terribly impressed by the C++ example either - don't expose pointers, use references instead, and the Builder certainly cannot be a singleton.  As an example, use more meaningful names - ideally (necessarily) the same as those in other examples to emphasis the relationship between the representations in different languages. 15.203.137.74 (talk) 12:19, 26 November 2014 (UTC)
thread_title:  Two example implementations 

message: I'm missing the critics section, because the builder pattern is just deeply bad Java, creating a unnecessary complex code and nothing else. Probably those people programming builders didn't understand what a constructor is and what a setter and a getter is. Too bad. It should be forbidden. Furthermore, builder are not real object oriented code, so they also need callback patterns, like in the old days with Fortran and C. But callbacks should nowadays be used only for asymmetric processes, and not for models at all. That's probably why we need (only) one new programming language in the future, prohibiting all those bad implementation patterns. Or, at least a Java compiler who prohibits it. 178.197.234.31 (talk) 13:36, 6 June 2013 (UTC)
replies: text: If somebody comes and says "how am I supposed to do fast parsing without a builder?", you are right in using a builder for loops, like a StringBuilder. But this is a very special case and is only used for parsing Strings. However, for normal objects you should use Externalizable to parse them (newer use Serialisation because it's only 30% Externalizable's speed). So please don't misunderstand me: Builder are okey in a very limited case of String parsing...but then we create the StringBuilder, use it instantly in a loop and afterwards we forget about it. But to use the builder pattern for more than String parsing is just dumb. 178.197.236.254 (talk) 14:36, 6 June 2013 (UTC)

text: Using setters is not a replacement, because setters can cause the object to have an unstable and incomplete form. Builder pattern guarantees that the only object that is modified is the intermediatate object used while creating the final product. When the intermediate object is used up it is discarded. Builder pattern also allows flexible object construction. Suppose you have an object that might need many parameters.  — Preceding unsigned comment added by 130.243.188.76 (talk) 22:50, 13 December 2013 (UTC)
thread_title:  Critics 

message: The java example is not the "GOF builder pattern". It's actually the "java builder pattern" (which is really a just a Fluent_interface). The GOF builder and the "java builder" are significantly different unrelated patterns. The java builder pattern is a wrapper for collecting settings used to eventually construct an object when you've collected enough. And it does it in an easy to read / write "sentence structure" ie: new CarBuilder().wheels(4).paint("blue").type("sedan").interior("leather").makeItSo();  You can use it to with a protected constructor so that all entities that want to build an object have to use the builder to do it. You can also use this java builder pattern in scala to build immutable objects. So that is the java builder pattern.  There's no director class for this type of builder. When the page is talking about the builder pattern being a wrapper around a constructor, its talking about the "java / fluent interface" pattern.
The GOF builder pattern is not like this at all. Whereas the java builder pattern is more about convenient sentence like construction, the GOF builder is more about building a complex/compound object using encapsulated builders (builders that no nothing about each other). And it uses a director to coordinate/orchestrate the work allocated to each builder to make the final compound object. So in the car example, you'd have builders that resemble steps in the car assembly with the director representing the "conveyor belt".
with that in mind, I think this page should just refer to the GOF pattern and have an ambiguity link to link the Java builder pattern to the Fluent_interface page.
http://stackoverflow.com/questions/26256604/is-the-java-builder-pattern-bloch-really-related-to-the-gof-builder
 Normana400 (talk) 18:47, 17 March 2017 (UTC)
thread_title:  page confusingly mixes two different unrelated builder patterns in its examples and explanations

message: The pseudocode example does not illustrate the full pattern as described in the GoF book. While we can identify a concrete Builder (CarBuilder) and the product (Car), the Director is somewhat implicit and there is no base Builder class to inherit from.
Javierieh (talk) 02:51, 11 November 2014 (UTC)
thread_title:  Wrong example 

message: The preface to the article suggests that the Builder Pattern is basically a solution for creating an object in a programming language where named arguments are not supported, but the member variables have default values that can be overridden, and if they are to be overridden, it should be done upon instantiation. So you create an auxilliary class that collects the arguments to a constructor and then creates the object.
So, in a programming language that does support named arguments, the pattern
disappears:
class Pizza:
   def __init__(self,dough='Hand Tossed', sauce='Marinara', topping='Cheese'):
      self.dough=dough
      self.sauce=sauce
      self.topping=topping
# Use the standard dough
p = Pizza(sauce='Garlic Butter', topping='Pepperoni')
...But then, the "Definition" section of the article says this:
The intent of the Builder design pattern is to separate the construction of a complex object from its representation. By doing so the same construction process can create different representations.
....which seems to have nothing to do with the purpose of the pattern, which is about specifying numerous optional arguments to a constructor by name. In the above paragraph it sounds like they're talking about being able to create a big endian representation of an integer or a string representation of the same integer with the same constructor class.
None of the code examples show a class that creates objects that offer different representations of the same value. All of the examples show classes that can selectively fill in member variables of the object that is about to be created. An object which only has one representation.
What the point would be of doing this is a separate question. 184.57.129.13 (talk) 12:20, 8 March 2015 (UTC)
replies: text: Keep in mind that here representation has the following meaning. Ftiercel (talk) 05:29, 9 March 2015 (UTC)
thread_title:  "Different representations": What? 

message: Some sections and examples switch between describing slightly different patterns:
1) Removing telescopic constructions by replacing them with a fluent-style interface. Basically a way of creating named optional parameters. This follows an item given in Effective Java.
2) Allowing clients to create complex objects by building parts separately. The client uses an interface so that different types of objects can be built by creating different concrete builders. This matches the Gang of Four book.
The introduction, C++, Java follow the first pattern.
Definition, Advantages, Disadvantages, Structure, PHP, C# follow the second pattern.
Should we make all the examples consistent, or at least explain the difference? As it is the article is contradictory and confusing. 81.187.215.34 (talk) 23:42, 22 June 2016 (UTC)
thread_title:  Contradictory sections 

message: The examples with ICarBuilder and CarBuilder don't seem quite right because there're no obvious different implementations of ICarBuilder possible. Because they have nearly the same name then the represent the same type instead of a supertype and subtype. If it was say VehicleBuilder and CarBuilder it might make more sense that there could be different concrete implementations.
A less abstract example might be DocumentBuilder with addParagraph, addImage etc methods. Then we could have a PdfDocumentBuilder, WordDocumentBuilder etc implementations. 81.187.215.34 (talk) 11:23, 10 July 2016 (UTC)
replies: text: The current example is no longer about cars. Dandv 04:33, 6 October 2022 (UTC)
thread_title:  ICarBuilder examples 

message: I would like to share the following UML diagrams I have published on Design Patterns Open Online Learning. Your comments are welcomed!
In the above UML class diagram, 
the Director class doesn't instantiate the ProductA1 and ProductB1 classes directly.
Instead, the Director refers to the Builder interface to create the objects,
which makes the Director independent of which concrete classes are instantiated (which representation of the complex object is created).
The Builder1 class implements the Builder interface by creating and assembling the ProductA1 and ProductB1 objects
The UML sequence diagram shows the run-time interactions: 
The Director object calls buildPartA() on the Builder1 object, which creates and assembles the ProductA1 object.
Thereafter, 
the Director calls BuildPartB() on Builder1, which creates and assembles the ProductB1 object. 
Vanderjoe (talk) 15:42, 5 August 2017 (UTC)
thread_title:  UML class and sequence diagram 

message: If the point of the article is to convey the idea behind the pattern, I think the many, many different language implementations are unnecessary. By display length, the Examples section, with implementations in 9 (!) different languages takes up 80% of the article. This seems quite superfluous, since, unlike, say, an article on a sorting algorithm, nobody is going to copy and paste any of this code into their program. 
I'd prefer to either completely remove the Examples section, or only keep, at most, a single language (don't care which).
Mlouns (talk) 22:43, 3 June 2019 (UTC)
replies: text: This was resolved. Can we delete the section? Dandv 04:32, 6 October 2022 (UTC)
thread_title:  The many code examples seem unneeded. 

message: I find the Pizza example given on this Talk page in 2007 (#Builders_and_immutable_objects) far easier to follow than the current Bicycle example. -- Dandv 04:30, 6 October 2022 (UTC)
thread_title:  Confusing Bicycle example