Builder Pattern

Key Insight

The Builder pattern separates the construction of a complex object from its representation, enabling the same construction process to yield different representations. This is highly beneficial in situations where the algorithm for creating an object should be independent of its constituent parts and their assembly, and when the construction process must support diverse representations for the final object. A motivating example is an RTF document reader capable of converting RTF into various text formats like plain ASCII, TeX, or an editable text widget, where the number of possible conversions is open-ended and new conversions should be addable without altering the reader's core logic.

The solution involves configuring an 'RTFReader' (the Director) with a 'TextConverter' (the Builder) object. As the 'RTFReader' parses the RTF document, it issues requests to the 'TextConverter' to convert each token, with specialized subclasses like 'ASCIIConverter' or 'TeXConverter' handling different conversion logic and output formats. This effectively separates the document parsing algorithm from the creation and representation of the converted format, allowing the 'RTFReader' to be reused with various 'TextConverter' subclasses. The pattern's participants include 'Builder' (abstract interface for product parts), 'ConcreteBuilder' (constructs parts and provides product retrieval), 'Director' (constructs object using 'Builder'), and 'Product' (the complex object under construction).

The Builder pattern offers several advantages: it allows variation in a product's internal representation by simply defining a new builder, as the builder hides the product's structure and assembly process behind an abstract interface. It isolates construction and representation code, enhancing modularity and ensuring clients do not need knowledge of the product's internal classes. Furthermore, it provides finer control over the construction process compared to patterns that create products in a single step, as the 'Director' controls the step-by-step assembly, only retrieving the complete product from the 'Builder' when finished. For example, a 'MazeBuilder' interface can define operations to build a maze, rooms, and doors, with 'StandardMazeBuilder' implementing these to create a concrete maze, while a 'CountingMazeBuilder' might instead just count the components, demonstrating different representations from the same construction process.