Creational Design Patterns
The problem
Directly calling new SomeClass() everywhere hardcodes exactly which concrete class gets created, making it impossible to swap implementations, control how many instances exist, or build up a complex object step by step — creational patterns are named, reusable solutions to controlling object creation itself.
Why now
SOLID's Dependency Inversion already established that code should depend on abstractions, not concrete classes — but something still has to create the concrete instance eventually. Creational patterns are exactly that 'somewhere' — a deliberate, isolated place where concrete construction happens, keeping the rest of the codebase depending only on the abstraction.
Mental model
Every creational pattern answers the same question — 'how and when does a concrete object get created' — differently: Factory hides which concrete class gets built behind a method, Builder constructs a complex object step by step instead of one giant constructor, Singleton guarantees exactly one instance exists, and Prototype creates new objects by cloning an existing one instead of building from scratch.
Requires
- Object-Oriented Programming BasicsLow-Level Design
Creational patterns are all about controlling how classes are instantiated into objects; you need classes and objects as the things being created before a pattern for creating them well is meaningful.
- SOLID PrinciplesLow-Level Design
Creational patterns exist largely to satisfy Dependency Inversion — isolating concrete construction in one place so the rest of the code can depend on abstractions instead of new SomeConcreteClass() scattered everywhere.
Unlocks
Used in
- Factory methods in countless frameworks (e.g. document.createElement, various ORM model factories)
- Builder pattern for objects with many optional configuration parameters
- Singleton for shared resources like a configuration object or connection pool
- Dependency injection containers, which are essentially factories managed by a framework
Projects
- Implement a Factory that creates different Shape subclasses based on an input string, so calling code never directly instantiates a concrete shape class
- Implement a Builder for an object with 8+ optional configuration fields (e.g. an HTTP request), replacing an unwieldy constructor with a fluent step-by-step API
Examples
- A ShapeFactory.create('circle') hides which concrete Circle class gets instantiated, so calling code only ever depends on the abstract Shape type
- A RequestBuilder.setUrl(...).setMethod(...).setHeader(...).build() avoids a constructor with 10 optional positional parameters, most of which are usually left as defaults
Resources
Mastery checklist
- I can implement a Factory pattern that hides concrete class selection behind an abstraction
- I can implement a Builder pattern for an object with many optional parameters
- I can explain when a Singleton is appropriate and its common pitfalls (hidden global state, testability)
- I can choose the appropriate creational pattern for a given object-construction problem