Creational Patterns: Who Decides What Gets Built

The word new is the most innocent-looking commitment in your codebase. new StripeGateway(...) reads like a detail. It isn’t. The moment a piece of business logic says new on a concrete class, it has married that class — its exact type, its constructor signature, its configuration — and it can no longer be tested, swapped, or reused without dragging the whole spouse along.

The smell they all push back on

Here is ordinary policy code. Nothing is “wrong” — it compiles, it ships. But look at how many creation decisions it has quietly nailed down inline, where no caller and no test can reach them.

Three separate kinds of coupling hide in that method: which tax class to build, how many gateways to open, and how to assemble an eight-argument invoice. Each is a different question — and each has its own creational pattern as the answer.

Pick the pattern by the pain

You don’t choose a creational pattern by its name; you choose it by the symptom you’re feeling. Select what hurts and watch it resolve to exactly one pattern.

The five, at a glance

The Gang of Four grouped these five together for a reason: each governs one creation decision, and reaching for the wrong one is usually a sign you’ve misread which decision is actually varying.

• Factory Method → — Let a subclass decide which concrete class to instantiate. Kills the switch(type) buried in shared logic. It moves which one class out of the policy.
• Abstract Factory → — Create families of related objects that must stay consistent. Kills the mismatched set (a macOS button beside a Windows checkbox). It moves a whole family out of the policy.
• Builder → — Assemble a complex object step by step, then validate once. Kills the telescoping constructor with eight parameters, half of them null. It moves step-by-step assembly out of the policy.
• Prototype → — Create new objects by cloning a ready-made one. Kills the expensive rebuild-from-scratch when you already hold a configured instance. It moves copying out of the policy.
• Singleton → — Guarantee exactly one instance behind a shared access point. Controls how many exist — the most abused of the five, and the one to reach for last.

Factory Method vs Abstract Factory — the one everyone confuses

They sit next to each other in the book and blur together in interviews, but the distinction is sharp: Factory Method produces one product and does it through inheritance — a subclass overrides the creating method. Abstract Factory produces a family of products and does it through composition — you hold a factory object and ask it for each member. Abstract factories are frequently built out of factory methods, which is exactly why they get conflated. One controls a class; the other controls a coherent set.

Both are also routinely confused with the simple factory — a single (often static) method with a switch that returns one product. It isn’t a GoF pattern at all; it’s the non-polymorphic baseline the two real factory patterns improve on, and it’s the right tool when one function is genuinely all you need.

Check yourself

References

Books

• Gamma, Helm, Johnson, Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software, the Creational Patterns chapter.
• Joshua Bloch — Effective Java (3rd ed.), Items 1–3 (static factories, builders, singletons).
• Erich Gamma et al. / Martin Fowler — Refactoring, on replacing hard-coded construction with substitutable creation.