Builder Pattern

The builder pattern separates the construction of an entity into two steps. In the first step, information is gradually collected in an intermediate form, and in the second step, the intermediate form is converted into the intended representation. The builder pattern is used whenever the best form for collecting information is not the best way to represent that information.

The builder pattern may be used in the creation of immutable data structures as an alternative to [[persistent data structures]]. The builder, in this case, would be mutable, and would be used to slowly collect values to be used in the construction of the immutable final form. Clojure transients are a good example of the builder pattern being used in functional programming. Rust can be used in a similar way, where a mutable reference is used to populate a variable before exclusively accessing that variable through immutable borrowed references. This use case might be referred to as a Construction Builder. (DSL's by Martin Fowler)

The builder pattern can also be used to create multiple different representations from the same raw data. In this variation, the builder entity is the same, but multiple conversion steps exist for each of multiple different representation forms. An alternative is to use [[Lenses]]. With lenses, the Builder would be retained, and the representations would be filled in by using different lenses on the Builder, though in this case it wouldn't be referred to as a "Builder."

The conversion step creates an opportunity to proactively perform expensive operations. Some computations are too performance intensive to be done on demand, like in the case of object properties or lenses, but must wait for data to be fully collected. In the naive case of gradual object construction, where properties are set as they are derived, the object might never be told when construction has officially completed and it should perform its final computation. If this is the case, [[Lazy Evaluation]] can be used to trigger computation, but this might cause undesirable stutters in performance as some operations in software seem to randomly trigger off excessive computation. An object might also monitor its own properties for completion, triggering expensive computation once all necessary data is present, but if the "complete" set of properties is ambiguous, or if properties are subject to change during the construction phase, this approach produces other performance issues.

The builder pattern is only applicable when the collection of data for an entity is gradual. If all of the data to construct the entity is available at one time, there would be no point in constructing an intermediate form before conversion to the final representation; you would just combine the steps into a constructor. For this reason, the builder pattern (or an alternative) is regularly used in processing files or parsing text—two instances where data is streaming into a system. A semantic model will often be constructed through some intermediate form.