Builder
Intent
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Motivation
An RTF reader must convert documents to multiple formats — plain text, TeX, a GUI widget. The reader parses RTF tokens and calls a TextConverter builder: ConvertCharacter(), ConvertParagraph(), ConvertFontChange(). Each concrete builder (e.g., TeXConverter) assembles the output in its own format.
Structure
The Director (RTFReader) drives the construction step by step. The Builder (TextConverter) declares the interface for creating parts. ConcreteBuilders implement those steps and provide a GetResult() method to retrieve the final product. The director doesn't know what's being built — it just follows the parsing algorithm.
Consequences
- Vary internal representation — new output formats only require a new builder, no changes to the parsing logic
- Isolates construction and representation — the director encapsulates how a complex object is assembled; the builder encapsulates how it's represented
- Finer control over construction — unlike one-shot factory methods, builder constructs products step by step, giving the director control over the process
Builder is everywhere in modern APIs: query builders, request builders, config objects with .setX().setY().build(). The key insight is separating the what to build from the how to build it.