Builder Pattern
Builder: start from the problem
See the responsibilities
A request configuration needs a destination, a timeout and optional headers. A long positional constructor makes it easy to exchange values or forget which defaults apply. Partially configured objects should not escape as usable clients.
This is a creational pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Builder addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Builder separates construction steps from the finished result. Named steps collect the intended configuration, and a final build operation validates the result. A director can supply a repeated sequence, but is optional.
Our builder makes the destination and timeout explicit. It creates a fresh configuration at build time. The builder’s fluent return value supports chaining; chaining alone is not proof that construction and validation are well designed.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
class RequestBuilder {
constructor() { this.options = {timeoutMs: 1000}; }
to(url) { this.options.url = url; return this; }
timeout(ms) { this.options.timeoutMs = ms; return this; }
build() {
if (!this.options.url || this.options.timeoutMs <= 0) throw new Error('Invalid config');
return {...this.options};
}
}
const config = new RequestBuilder().to('/orders').timeout(500).build();
console.log(config.url + ' ' + config.timeoutMs);Expected output
/orders 500Choose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it for several optional construction choices, validation rules or repeatable assembly steps. Immutable finished objects can help make configuration ownership clear.
A builder can itself become a mutable state trap if reused across concurrent requests. For a small record with a few defaults, an options object and validation function may be easier. Validate ranges and supported combinations, not only field presence.
Distinguish the neighbouring patterns
Abstract Factory selects a compatible family. Builder assembles a particular result. Factory Method chooses a product at an extension point in a creator’s workflow.
Follow Abstract Factory’s product families, Factory Method’s creation step, why request deadlines need deliberate budgets to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Builder, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside why request deadlines need deliberate budgets.
Reaching the recap and completing the quizzes are separate milestones.