Creational Design Patterns
All 23 classic Gang of Four patterns for object-oriented software design.
A design pattern is a general, battle-tested solution to a problem that recurs often in software design. It isn't ready-made code - it's a reusable template you adapt to your own situation.
The idea comes from architecture: in 1977, architect Christopher Alexander described recurring solutions for building towns and buildings as a "pattern language" - each entry being a problem, the context it shows up in, and a proven solution. In 1994 the "Gang of Four" applied the same approach to object-oriented programming.
All 23 patterns come from the book "Design Patterns: Elements of Reusable Object-Oriented Software" (1994) - its authors, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, became known as the "Gang of Four" (GoF), and the book is still the standard reference for object-oriented design vocabulary.
Every pattern in the book follows the same template: name, problem it solves, motivation, applicability, class structure, participants, consequences (trade-offs), and a sample implementation. This site follows the same structure for each of the 23 patterns.
The patterns fall into three groups:
- Creational patterns hide the logic behind object creation, letting a program decide at runtime which class to instantiate instead of hard-coding it.
- Structural patterns show how to assemble classes and objects into larger structures while keeping them loosely coupled and easy to change later.
- Behavioral patterns describe how objects split up responsibilities and communicate, reducing tight coupling and making interactions more predictable.
Creational
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
Structural
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
Behavioral
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template Method
- Visitor
Knowing these patterns helps developers speak a shared vocabulary, read unfamiliar code faster, and reach for proven solutions instead of reinventing the wheel.
A pattern is not a goal in itself and not a sign of "correct" code. Applying one where the problem doesn't call for it just adds unnecessary abstraction. Reach for a pattern when it actually solves a problem you have, not because it's "the proper way" to do things.
Abstract Factory
Produces whole families of related objects through one interface, so the objects always match.
Builder
Assembles a complex object step by step, so the same steps can yield different configurations.
Factory Method
Delegates object creation to a method subclasses can override, hiding the exact type being built.
Prototype
Creates new objects by cloning an existing instance instead of building one from scratch.
Singleton
Guarantees a class has exactly one instance and gives the whole program one way to reach it.