Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

confusion on builder pattern

 
Titi Wangsa Damhore
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
source #1
wikipedia: https://en.wikipedia.org/wiki/Builder_pattern
the "Pseudocode" section is what i think it is
Construct a CarBuilder called carBuilder
carBuilder.setSeats(2)
carBuilder.setSportsCar()
carBuilder.setTripComputer()
carBuilder.unsetGPS()
car := carBuilder.getResult()
so is this

source #2: stack overflow
http://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern


so my understanding is to create one type of object, but the constructor might be different
instead of
Pizza pizza = new Pizza(true, false, true, true, false, false, false, false)
we know what is true and that is not ( cheese true)

source #3:
http://sourcemaking.com/design_patterns/builder/java/2

sample code

source #4:
http://www.tutorialspoint.com/design_pattern/builder_pattern.htm


i see that sometimes, its new Builder().setPropertyA().setProertyB(10.4).setPropertyM(-1).build()
sometimes its different.

are some of the examples wrong?
or both are correct?

thanks.
 
Aaron Shawlington
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All of those examples are doing the same thing - although in some you only showed the client code that uses the builder, while in others you only showed the actual builder code.

Either way, the builder is being 'configured' in some way before you then do 'build()' - at which point all of that configuration is used to construct the appropriate object.

In some of those examples the builder just created 1 type of object, but in varying configurations.
In other examples, the builder was configured to build different types of object (with a common base type) which also have different configuration options within each type.


View this in contrast with the factory pattern, which is responsible for obtaining specific objects, sometimes of a specific type when the caller only asked for the interface type (abstract factory). The point is that the factory just gets an object (either builds one in one go - or gets something else to build it for it). Perhaps I have 10 places in my code which need a particular object - they don't all want to have to change its configuration every time some requirement changes - so they ask a factory for it and then when soemone changes their mind only the factory (1 place) has to change.

The builder, on the other hand, builds up complicated objects step by step (and it has the advantage of being able to make sure that you can't build a half-initialised object because the whole thing gets build properly before the /build() method returns it).


In reality, the factory patter is often used in conjunction with the builder pattern - the factory might be configured with a builder which it used to build the object that someone else asked for. In this way the client code doesn't necessarily have to know anything about how th eobject it asked the factory for is configured etc.It just gets given it and trusts that its good for the job - in that way the client code can focus on it's own responsibility while the factory and or builder focusses of the responsibility for building stuff with the correct configuration (database connections, adaptors for converting between json to objects, etc etc, for example).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic