Creational Patterns

Builder replaces a long constructor argument list. You set values one named step at a time, skipping the ones you do not need, then call build() to get the finished object. It is easier to read and harder to mix arguments up.

They separate creating an object from using it. Instead of calling a concrete constructor directly, code asks something else to produce the object — so the system can change which class is built, and how, without editing every caller.

Factory Method hides object creation behind an overridable method. Code that needs an object calls that method instead of naming a concrete class directly, and a subtype (or implementation) decides which concrete class actually gets built.

Some objects are slow or costly to create — database connections, threads, sockets, large buffers. An Object Pool keeps a fixed set of them alive and ready. Callers borrow one, use it, then give it back instead of creating and destroying it each time.

Prototype creates a new object by copying an existing, already-configured object instead of building one from scratch. You ask the existing instance to clone itself. It helps when construction is slow or the setup is long and fiddly.

Singleton ensures a class has exactly one instance and one shared way to reach it. Unlike a plain global variable, the class hides its own constructor and creates the instance itself, so no other code can make a second one.

Factory Method has one creation method for one product kind and varies it by subclassing the creator. Abstract Factory is an object with several creation methods covering a whole family of related products, and you vary it by swapping which factory object you pass in.

The builder holds the values while you fill them in; the real object is created only once, at build(), through a private constructor. So the product needs no setters and can be immutable, and build() is a single place to check rules that involve several fields together.

Factory Method is one overridable method on a class; a subclass decides which single product to create. Abstract Factory is a separate object with several creation methods that produce a whole family of related products that must match each other.

A simple factory is one method with a switch that picks the class; adding a type means editing that method. Factory Method is an overridable method — adding a type means adding a new subtype that overrides it, leaving existing code untouched.

The pool can make the caller wait until someone returns an object (usually with a timeout), fail fast with an error, or — in a soft-limited pool — create a temporary extra instance. Waiting forever is the dangerous option: it can hang the whole system.

Because the same object is reused by different callers. If one caller's leftover state — an open transaction, a half-filled buffer, a per-user setting — survives, the next caller silently inherits it. That causes wrong results and can leak one user's data into another user's request.

A shallow copy duplicates the object's own fields, so reference fields still point at the same nested objects — original and copy share them. A deep copy also duplicates those nested objects. Choosing shallow wrongly means editing the copy silently changes the original.

Two threads can both see the field as empty and each create an instance, so you end up with two. Fix it by creating the instance eagerly at class load, or by guarding the check-and-create with a lock or a run-once primitive.

Classic Singleton hides a global variable behind a static accessor: callers reach for it directly, so dependencies are invisible, tests can't substitute it, and shared mutable state plus lazy initialization creates concurrency problems. A DI container keeps one instance per scope but injects it, so dependencies stay explicit and replaceable.

Singletons are global mutable state reached through a static call, so dependencies are invisible in signatures, state leaks between tests, and you cannot substitute a fake. Dependency injection keeps one shared instance but passes it in explicitly, so it stays visible and replaceable.

Factory Method and Abstract Factory answer "which class do I create?" and do it in one call. Builder answers "how do I assemble this one complicated object?" across many calls. Use a factory to hide the concrete type; use a builder for many optional parts.

Use Builder when an object has many optional or order-dependent parts and a constructor would become a long, unreadable parameter list. Use Prototype when creating a fresh object is expensive or its configuration is easier to copy from an existing instance than to specify again.

Business logic calls an overridable creation method and uses only the product interface, so it never names a concrete class. New behaviour arrives as a new subtype (extension, no edits), and the logic depends on abstractions rather than on concrete implementations.

A prototype registry is a lookup table from a key to a ready-made, configured object. Clients ask for a key and clone what comes back. You prefer it when new variants differ only in configuration, so adding one means adding data, not code.

Eager creation happens at startup: simple, thread-safe for free, and failures show up immediately — but you pay the cost even if the object is never used. Lazy creation defers the cost to first use, at the price of needing thread-safe initialization.

Adding a new product kind means adding a method to the factory interface, so every existing concrete factory must implement it. Adding a new variant is cheap; adding a new kind is expensive. Mitigations include default implementations, splitting the interface, or a registry keyed by product type.

Skip it when there is only one variant, when the products do not have to match each other, or when objects need lots of runtime arguments. A DI container binding, a configuration switch at startup, or plain constructor injection usually covers the need with less machinery.

The fluent builder mainly names optional parameters for one class. The original Builder has an interface with several implementations plus a Director that calls the steps in a fixed order, so one construction process can produce different outputs — for example the same document walk emitting HTML or plain text.

Simplest: take required values in the builder's constructor or factory method, and check the rest in build(), throwing if something is missing. Stronger: a staged builder, where each step returns a different type that only exposes the next required step, so forgetting one will not compile.

It adds a class hierarchy and indirection: more types to read, harder to see what actually gets created, and extension only via subclassing. Skip it when there's one implementation, when a plain function or injected dependency suffices, or when selection is data-driven.

Factory Method varies one product through one overridable method. Abstract Factory groups several related products behind one interface so a whole family swaps together. Builder assembles one complex object step by step when it has many optional parts.

A leak is when code borrows an object from the pool and never returns it — usually because an exception skipped the return call. The pool slowly runs out of instances until every request hangs or times out, often long after deploy.

Pool only things that are genuinely expensive to create, like connections or threads. Pooling ordinary in-memory objects on a garbage-collected runtime is usually slower and adds bugs: leaks, leftover state, and lock contention on the pool itself.