Builder
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Mujtaba Alshakhouri) |
|||
| (5 intermediate revisions by 5 users not shown) | |||
| Line 7: | Line 7: | ||
* There need to be different representations of the object to be constructed | * There need to be different representations of the object to be constructed | ||
* The creation algorithm should be independent of the parts of the object and how they are assembled | * The creation algorithm should be independent of the parts of the object and how they are assembled | ||
| + | * Runtime control over the creation process is required | ||
| + | * Need to add new creational logic without changing the existing code | ||
== Structure == | == Structure == | ||
| Line 43: | Line 45: | ||
A classic example is for a RTF (Rich Text Format) reader, which is able to convert the RTF text to a variety of text formats (ASCII, TeX, etc). Using the builder allows new text formats to be easily added later. It separates the RTF parser algorithm from the creation and representation of the converted format. | A classic example is for a RTF (Rich Text Format) reader, which is able to convert the RTF text to a variety of text formats (ASCII, TeX, etc). Using the builder allows new text formats to be easily added later. It separates the RTF parser algorithm from the creation and representation of the converted format. | ||
| + | |||
| + | === Another Example === | ||
| + | You can find [http://java.dzone.com/articles/design-patterns-builder here] a nicely explained java code example of the Builder Pattern usage in the real world. | ||
== Consequences == | == Consequences == | ||
| Line 48: | Line 53: | ||
* Construction and representation code are separated, supports encapsulation. Different Directors can build Product variants from the same set of parts. | * Construction and representation code are separated, supports encapsulation. Different Directors can build Product variants from the same set of parts. | ||
* Constructs a Product step by step, giving greater control over the construction compared to other creational patterns. | * Constructs a Product step by step, giving greater control over the construction compared to other creational patterns. | ||
| + | |||
| + | ==Related Patterns== | ||
| + | * [[Abstract Factory]]: The [[Abstract Factory]] pattern is similar to Builder in that it also constructs complex objects. However, Builder focuses on the creation steps while [[Abstract Factory]] emphasizes product families. Therefore, Builder returns the complete product only after the final step while [[Abstract Factory]] returns the product immediately. | ||
| + | * [[Composite]]: A Builder is often used to build a [[Composite]]. | ||
== See also == | == See also == | ||
* [[Design patterns]] | * [[Design patterns]] | ||
| + | |||
| + | {{design patterns}} | ||
Latest revision as of 03:22, 25 November 2010
The Builder pattern allows you to use the same construction process to create different representations of a complex object, and makes it easy to extend more representations in the future.
Contents |
Use when
- There need to be different representations of the object to be constructed
- The creation algorithm should be independent of the parts of the object and how they are assembled
- Runtime control over the creation process is required
- Need to add new creational logic without changing the existing code
Structure
From the Gang of Four Design Patterns book:
Builder
- Abstract interface which defines methods for constructing each part of a Product
ConcreteBuilder
- Implements the methods for constructing each part of the Product
- Defines the process by which the Product is assembled
- Defines and tracks the created product
- Provides an interface to retrieve the product
Director
- Uses the Builder interface to construct an object
Product
- The complex object under construction
- A class for each part of the Product, and interfaces for assembling the parts
Collaborations
- The client creates a Director, configures it with desired ConcreteBuilder.
- Director tells the Builder to build parts of the Product
- Builder creates the parts and adds them to the Product
- Client retrieves product from Builder
Example
From the Gang of Four Design Patterns book:
A classic example is for a RTF (Rich Text Format) reader, which is able to convert the RTF text to a variety of text formats (ASCII, TeX, etc). Using the builder allows new text formats to be easily added later. It separates the RTF parser algorithm from the creation and representation of the converted format.
Another Example
You can find here a nicely explained java code example of the Builder Pattern usage in the real world.
Consequences
- A Products internal representation can be varied, the Director only knows about the abstract Builder class
- Construction and representation code are separated, supports encapsulation. Different Directors can build Product variants from the same set of parts.
- Constructs a Product step by step, giving greater control over the construction compared to other creational patterns.
Related Patterns
- Abstract Factory: The Abstract Factory pattern is similar to Builder in that it also constructs complex objects. However, Builder focuses on the creation steps while Abstract Factory emphasizes product families. Therefore, Builder returns the complete product only after the final step while Abstract Factory returns the product immediately.
- Composite: A Builder is often used to build a Composite.
See also
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
