How do you decide how much creational indirection a system actually needs — and what signals tell you a factory or builder layer should be removed rather than added?

## Framing: indirection is a purchase, not a virtue Every creational pattern buys **flexibility at a specific variation point** and pays in **types, indirection, and traceability**. The senior mistake is adding it reflexively; the equally common mistake is refusing it until the code is unchangeable. The discipline is to name the force before adding the pattern. ## The four questions that decide it **1. What varies?** If nothing varies, no pattern. Name the axis explicitly: | Varying axis | Mechanism | |---|---| | how many instances | lifetime/scope policy (DI scope; Singleton only as a last resort) | | which concrete class, chosen by a subclass of the consumer | Factory Method | | which *set* of matching classes | Abstract Factory (or DI profile) | | how a complex object is assembled | Builder | | starting state, copied from an existing instance | Prototype / copy-with | **2. When must the binding happen?** Compile time (just call the constructor) → build/link time (a module or package boundary) → startup (config file, environment variable, DI profile) → per request/per call (a factory taking runtime arguments). Choose the cheapest mechanism that reaches the required binding time. Deferring later than necessary is pure cost. **3. Who owns the choice?** A framework author exposing an extension point reaches for Factory Method. An operator choosing an environment reaches for configuration/DI. A caller who knows something at the moment of the call passes an argument or uses a builder. **4. What invariant must be impossible to break?** This is the strongest justification. "A dark button can never appear next to a light scrollbar" and "a half-initialized `Request` can never be observed" are invariants the type system can enforce through Abstract Factory and Builder respectively. Indirection that encodes an invariant earns its keep; indirection that only anticipates change often does not. ## Signals to remove creational machinery - **One-implementation interface + factory.** `PaymentGatewayFactory` returning `StripeGateway`, forever. Constructor injection of the concrete type already gives testability if it implements an interface — the factory adds nothing. - **Passthrough methods.** Every factory method is `return new X(a, b)` with no decision, caching, validation, or defaulting. - **Switch-on-type factories that keep growing.** Each new type edits the factory: the abstraction failed at its one job (Open/Closed). Either register implementations in a map keyed by type (or let the DI container do it), or accept that a simple constructor call is more honest. - **Builders for tiny value objects**, especially in languages with named/default arguments or records. - **Unanswerable production questions.** If "which implementation runs in production?" requires reading three config layers and a container registry, the indirection has exceeded comprehension budget. - **Frameworks already doing it.** Hand-rolled Singletons alongside a DI container; hand-written factories duplicating container registrations; `clone()` machinery on objects that could simply be immutable. - **Abstractions built for a variation that never came.** Delete on the second year of a single implementation; you can reintroduce it in an afternoon when the second one appears. ## Signals to add it - A **second real implementation** exists or is contractually committed (a new region, vendor, tenant, protocol version). - A **strangler/migration** is planned: routing between old and new implementations at runtime. - A **construction bug class has occurred**: mismatched families, half-initialized objects, transposed positional parameters. - **Construction cost** dominates and copying a warm instance is measurably better. - **Extension by third parties** is a product requirement (plugins must supply their own products). ## Modern erosion of the classic catalogue Much of the GoF creational tooling has been absorbed: - **DI containers** replace hand-written Abstract Factories and Singletons with registrations and scopes. - **Named/default arguments, records, and data-class copy** replace most Builders and much of Prototype. - **Higher-order functions/lambdas** replace many one-method factories: pass `() -> Connection` rather than declaring a `ConnectionFactory` interface. - **Immutability** removes deep-copy hazards entirely. The *intents* survive; the boilerplate largely does not. A principal-level answer names the intent, then chooses the lightest mechanism available in the platform — and says so explicitly, rather than reciting the 1994 class diagrams. ## Organizational dimension At scale, creational seams are also a **team boundary** device: a factory interface owned by a platform team is the contract product teams implement. That justifies indirection that a single-team codebase would not need — the flexibility is bought for organizational, not technical, reasons. Conversely, factories introduced by a team that never owned a second implementation are usually just cargo cult, and removing them is a legitimate, low-risk cleanup.