Implement the Builder pattern with a fluent API. What problem does it solve that a constructor doesn't?
Recognising the telescoping-constructor / many-optional-params smell and solving it with incremental, readable, chainable construction.
Builder separates the construction of a complex object from its representation, letting you assemble it step by step. The signal: a constructor with many parameters, most of them optional — the 'telescoping constructor' smell where call sites read `new Request(url, null, null, 'POST', headers, null, true)` and nobody can tell what the nulls mean. A Builder replaces that with named, chainable steps: `new RequestBuilder(url).method('POST').header('Auth', t).json(body).build()`. Each setter mutates internal state and RETURNS `this`, which is what enables the fluent chaining; a final `build()` validates and returns the finished (ideally frozen/immutable) object. Benefits: call sites are self-documenting, order-independent, and you only specify what you need; you can enforce invariants in `build()` (required fields present, mutually-exclusive options rejected); and you can produce an immutable result while keeping construction ergonomic. This is everywhere in frontend tooling — query builders (Knex), request builders, test-data builders, and fluent config APIs. Contrast with Factory: a Factory decides WHICH object to make in one call; a Builder assembles ONE known object gradually across many calls. Don't reach for it when a plain object literal or a single options object (`fn({ method, headers })`) is already clear — Builder earns its keep only when construction is genuinely multi-step or needs staged validation.
Objects with many optional parameters, staged/validated construction, or a readable fluent API — query builders, request/config builders, test-data factories.
O(k) for k build steps.