Applied Design Patterns with Java
Creational :: Builder (97) {C ch 7}
Implementation
Typically there's an abstract Builder class that defines an operation
for each component that a director may ask it to create. The operations do nothing by default. A ConcreteBuilder
class overrides operations for components it's interested in creating.
Here are other implementation issues to consider:
- Assembly and construction interface. Builders construct their
products in step-by-step fashion. Therefore the Builder class interface must be general enough to allow the construction of products
for all kinds of concrete Builders. A key design issue concerns the model for the construction and assembly process.
A model where the results of construction requests are simply appended to the product is usually sufficient.
- Why no abstract class for products? In the common case, the products produced by the concrete builders differ so greatly in
their representation that there is little to gain from giving different products a common parent class. Because
the client usually configures the director with the proper concrete builder, the client is in a position to know
which concrete subclass of Builder is in use and can handle its products accordingly.
- Empty methods as default in Builder. In C++, the build methods are intentionally not declared pure virtual member functions.
They're defined as empty methods (stubs) instead, letting clients override only the operations they're interested in.
Related Patterns
Abstract Factory (87) is similar to Builder in that it too may construct complex objects. The primary difference
is that the Builder pattern focuses on constructing a complex object step by step. Abstract Factory's
emphasis is on families of product objects (either simple or complex). Builder returns the product
as a final step, but as far as the Abstract Factory pattern is concerned, the product gets returned immediately.
A Composite (163) is what the Builder
often builds.
Catalog Creational Prev Next