Creational patterns are the Gang of Four family that put a layer between “I need an object” and “here is exactly how it gets built,” so the rest of the code does not hard-code which concrete class to instantiate.12
The problem they solve
When code says new ConcreteThing(...) directly, two things get baked in: the decision
of which type to use and the details of how to construct it. That binding hurts when the
type should depend on runtime input, construction is complicated, or you want exactly one
shared instance. Creational patterns isolate that logic so callers depend on an
interface, reducing coupling
and honouring the open/closed principle from SOLID.1
The main members
- Factory / Factory Method — create and return an object through a common interface so the caller never names the concrete class; Factory Method defers the choice to a subclass-overridable step.
- Abstract Factory — create whole families of related objects (a matching decoder, filter, and display for a mode).
- Builder — assemble one complex object step by step with named, chainable steps, ideal when a single constructor would be an unreadable wall of arguments.
- Prototype — create new objects by cloning an existing instance.
- Singleton — guarantee one shared instance with global access.
Notes and caveats
Use a Factory when which type varies; use a Builder when how one complex object is built varies — they compose well, since a factory can use a builder internally. Singleton is often an anti-pattern: it is global mutable state in disguise, with hidden dependencies and poor testability, so prefer passing a shared instance in explicitly. The sibling families are structural patterns (arranging objects) and behavioral patterns (coordinating them).
Sources
-
Creational pattern — Wikipedia, for the definition and the family members (Factory Method, Abstract Factory, Builder, Prototype, Singleton). ↩ ↩2
-
Design Patterns — Wikipedia, on the 1994 Gang of Four book that established the creational/structural/behavioral grouping. ↩