Creational Patterns

Intent

Creational patterns hand the responsibility of creating objects to dedicated, replaceable machinery so the rest of your code can depend on abstractions instead of concrete constructors.

Problem

The simplest way to make an object is to call its constructor directly. That works until the moment your code needs to choose between several concrete types, share a single instance, assemble an object in many small steps, or copy an existing object cheaply. Every new Thing() sprinkled through a codebase is a hard-wired decision: change the class and you change every caller. Creational patterns gather those decisions into one place so creation logic can evolve without rippling through everything that uses the result.

Each pattern in this module attacks a different slice of that problem. They are not competitors; experienced designers reach for whichever one matches the constraint in front of them, and often combine several in one system.

Structure

This module covers the five classic creational patterns and how they relate.

classDiagram
  class CreationalPattern {
    <<concept>>
    +produce() Product
  }
  class Singleton {
    +instance() Singleton
  }
  class FactoryMethod {
    +create() Product
  }
  class AbstractFactory {
    +createA() ProductA
    +createB() ProductB
  }
  class Builder {
    +step()
    +build() Product
  }
  class Prototype {
    +clone() Prototype
  }
  CreationalPattern <|.. Singleton
  CreationalPattern <|.. FactoryMethod
  CreationalPattern <|.. AbstractFactory
  CreationalPattern <|.. Builder
  CreationalPattern <|.. Prototype

The five creational patterns and their shared role

The five patterns at a glance:

Singleton — guarantees a class has exactly one shared instance and gives everyone a single point of access to it.
Factory Method — lets a base class defer the choice of which concrete product to instantiate to its subclasses.
Abstract Factory — produces whole families of related products through one interface, keeping the family members consistent.
Builder — separates the step-by-step assembly of a complex object from its final representation.
Prototype — creates new objects by cloning an existing instance instead of constructing from scratch.

When to use / trade-offs

Pro: creation logic lives in one place, so swapping implementations rarely touches calling code.
Pro: calling code depends on interfaces, which makes testing and substitution easier.
Con: every pattern adds indirection; on a tiny program a plain constructor is clearer.
Con: misapplied, these patterns produce ceremony without benefit — reach for them only when the creation problem is real.