Builder Pattern
Builder PatternIntent: Separate the steps for constructing of a complex object from its final representation so that (a) an object with strict properties (e.g. immutable, or say, maxTemperature >= minTemperature) can be configured in less strict steps, (b) avoid hard-to-remember/understand chatty constructors with many arguments, and (c) where possible allow the caller to reuse steps for creating similar instances.
See also: ClassFactory, AdapterPattern
http://home.earthlink.net/~huston2/dp/builder.html
http://wiki.cs.uiuc.edu/patternStories/BuilderPattern
Given that a CompositePattern is often what BuilderPattern builds, is there a corresponding DestroyerPattern? that can nicely remove pieces of a CompositePattern?
How is this different from a factory pattern?
In the factory pattern, the caller delegates the construction of objects to a factory and is shielded from (made of ignorant of) the details of how the objects are to be constructed / configured. So in the factory pattern, the caller typically invokes a factory method with one or zero arguments.
The BuilderPattern, by contrast, is all about the details of object construction. For example, if the object being constructed has rich properties and needs to be immutable, then the builder pattern is a good fit. An example use case in Java is the java.lang.StringBuilder which creates immutable java String objects (via the former's toString() method). Another use case for the builder pattern is when the constructor of the object to be built must take very many parameters. In such cases, it is often more convenient to lump such configuration parameters in a builder object ( setMaxTemperature(int t), setMinTemperature(int t), set.. , etc. ) than to burden the caller with a long list of arguments to pass in the class's constructor. --Babak Farhang
So the BuilderPattern is similar to FactoryPattern, but creates a complex object using a number of steps.
If the product is a CompositePattern you may need to remove some of the pieces later. If I understand correctly, you are proposing to just create an entirely new composite from the factory. What I am wondering is whether patterns have been explored that reverse some of the steps from a BuilderPattern. In other words, modifying the composite built by a builder by performing the reverse of some of the steps used to build it. An example would be a tree built from parsed data. Later you may want to parse an update that removes a few nodes and adds a few nodes to the original. Much of the logic from the original builder applies, but some of the operations destroy instead of build.
Hmmm. Interesting. Maybe instead of just having BuildPartA, BuildPartB methods, you also have DestroyPartA and DestroyPartB methods?
Essentially,I find no difference between a Abstract Factory Pattern and Builder .Assume there is no family of products but just a list of independent products.Also let it be so,that instead of the client using the Factory to create objects, we have one more class (director) which encapsulates all that the client should do..We have a builder pattern here.It's no pattern.. just a wrapping up together what a client should do..It's just a specialized case of Abstract factory pattern ..Praveen George
Abstract factory is the answer to what and the builder to how.
Does that mean builder can be the consumer of the products of an Abstract Factory??
A Builder can be one of implementations of the AbstractFactory. Of course it can use other factories to build the parts of its product.
PleaseComment: A class that gives some convenient shortcuts for creating a complex object through a builder, would that be a factory? Imagine you have a builder you can create some product with. Now, you want to build such a product by fetching contents one by one from a network connection (or any other long running operation that can be canceled). So you create two convenience methods, one that creates the object structure from scratch and one that resumes a previously canceled one, both calling the builder. Would you call these factory methods? You could put both methods into a single class to abstract from the exact calling order (you could parallelize the network fetching e.g.). Would that be a factory?
And Abstract factory in fact could be creating builders??Yes :-) A MetaFactory?
AnswerMe: I'm not sure this belongs here, so feel free to move it if it doesn't. How do you handle cases where the concrete objects need different types of parameters when constructed? For example, my MFCWidget needs a CWnd*, but my FlashWidget needs a CShockwaveFlash*?
If the objects to be created have different interfaces, then they shouldn't be grouped together with a Factory in the first place. Construction parameters can be different, but the factory should hide those differences. Try thinking about why you would even need to have a common factory interface for MFCWidget and FlashWidget?. By the way, this question probably belongs on the AbstractFactoryPattern or FactoryMethod page.
Wouldn't you say that each individual Builder is a Factory? The whole pattern seems substantially different from Factory or AbstractFactory when implemented properly.
I've implemented this pattern, and the way I've understood it is:
I've got a PageView? that has lots of widgets on it. These widgets need to be built with an AbstractFactory. Each widget has many other elements nested into it. The PageView? is the builder. It provides context to Abstract Factories. My widgets with nested elements could be called builders as well.
As for the CWnd*/CShockwaveFlash question. This variablity can be handled with the AdapterPattern. You wrap that complexity with another object and perhaps create another AbstractFactory to build it. Supply a variable to hold the value and then when it's included in the BuilderPattern object, you just have to look at the value and load.
For an example usage see TestDataBuilder.
EditText of this page
(last edited October 29, 2011)
or FindPage with title or text search