Design Patterns
All 20 Gang of Four design patterns with UML class diagrams, detailed descriptions, and implementations in Java, Python & C# — organised by Creational, Structural, and Behavioral categories.
Design patterns are reusable solutions to recurring design problems. The Gang of Four (GoF) catalogued 23 patterns in three categories. This page covers the 20 most essential patterns with UML diagrams and tri-language code examples.
| Category | Patterns | Focus |
|---|---|---|
| Creational (5) | Singleton, Factory Method, Abstract Factory, Builder, Prototype | Object creation mechanisms |
| Structural (7) | Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy | Object composition & structure |
| Behavioral (8) | Observer, Strategy, Command, Template Method, Chain of Responsibility, State, Mediator, Visitor | Object communication & responsibility |
Creational Patterns
Creational patterns abstract the instantiation process — they make a system independent of how its objects are created, composed, and represented.
Singleton
- One instance, global access
Factory Method
- Subclass-driven creation
Abstract Factory
- Product family creation
Builder
- Step-by-step construction
Prototype
- Clone-based instantiation
When to use: Use when exactly one instance is needed — loggers, config managers, thread pools, caches.
| Component | Role |
|---|---|
| Static Instance | Holds the single instance |
| Private Constructor | Prevents external instantiation |
| getInstance() | Returns the sole instance |
When to use: Use when a class cannot anticipate the type of objects it needs to create.
| Component | Role |
|---|---|
| Creator | Declares the factory method |
| ConcreteCreator | Overrides factory method |
| Product | Interface for objects |
| ConcreteProduct | Specific implementation |
When to use: Use when products come in families that must be used together (e.g. cross-platform UI).
| Component | Role |
|---|---|
| AbstractFactory | Interface for creating families |
| ConcreteFactory | Creates specific family |
| AbstractProduct | Interface per product type |
| Client | Uses only abstract interfaces |
When to use: Use when constructing complex objects with many optional parameters.
| Component | Role |
|---|---|
| Builder | Step-by-step interface |
| ConcreteBuilder | Builds the product |
| Director | Orchestrates order |
| Product | Complex object built |
When to use: Use when object creation is expensive or you need copies with slight variations.
| Component | Role |
|---|---|
| Prototype | Interface with clone() |
| ConcretePrototype | Implements cloning |
| Client | Requests clones |
- Singleton — one instance, global access (use sparingly)
- Factory Method — subclasses decide which class to instantiate
- Abstract Factory — create families of related objects
- Builder — construct complex objects step by step
- Prototype — clone existing objects to avoid costly creation
Structural Patterns
Structural patterns deal with object composition — how classes and objects are assembled to form larger structures while keeping them flexible and efficient.
Adapter
- Interface conversion
Bridge
- Abstraction / impl split
Composite
- Tree structures
Decorator
- Dynamic behaviour
Facade
- Simple interface
Flyweight
- Memory sharing
Proxy
- Access control
When to use: Use when you want to use an existing class but its interface is incompatible.
| Component | Role |
|---|---|
| Target | Interface client expects |
| Adapter | Bridges target and adaptee |
| Adaptee | Existing incompatible class |
When to use: Use when you want to avoid a permanent binding between abstraction and implementation.
| Component | Role |
|---|---|
| Abstraction | High-level interface |
| Implementor | Low-level interface |
| RefinedAbstraction | Extended abstraction |
| ConcreteImplementor | Specific implementation |
When to use: Use when clients should treat individual objects and compositions uniformly.
| Component | Role |
|---|---|
| Component | Common interface |
| Leaf | Primitive element |
| Composite | Has children components |
When to use: Use to add behaviour to objects without subclass explosion.
| Component | Role |
|---|---|
| Component | Interface |
| ConcreteComponent | Base object |
| Decorator | Wraps component |
| ConcreteDecorator | Adds behaviour |
When to use: Use to reduce coupling between clients and a complex library or subsystem.
| Component | Role |
|---|---|
| Facade | Simple unified interface |
| Subsystem classes | Complex internal components |
When to use: Use when many similar objects consume too much memory (text editors, game particles).
| Component | Role |
|---|---|
| Flyweight | Shared intrinsic state |
| FlyweightFactory | Manages shared instances |
| Client | Provides extrinsic state |
When to use: Use for lazy loading, access control, logging, or caching.
| Component | Role |
|---|---|
| Subject | Common interface |
| RealSubject | Actual object |
| Proxy | Controls access to real subject |
- Adapter — convert one interface to another
- Bridge — separate abstraction from implementation
- Composite — treat individual and composite objects uniformly
- Decorator — add behaviour without subclassing
- Facade — simplify complex subsystem interfaces
- Flyweight — share state to reduce memory
- Proxy — control access to an object
Behavioral Patterns
Behavioral patterns are concerned with communication between objects — how responsibilities are assigned and how algorithms are encapsulated.
Observer
- Event notification
Strategy
- Swap algorithms
Command
- Encapsulate requests
Template Method
- Algorithm skeleton
Chain of Resp.
- Handler pipeline
State
- State-based behaviour
Mediator
- Central coordination
Visitor
- Add operations
When to use: Use for event systems, pub/sub, reactive UI updates.
| Component | Role |
|---|---|
| Subject | Maintains observer list |
| Observer | Interface for notification |
| ConcreteObserver | Reacts to changes |
When to use: Use when you need to switch algorithms at runtime (sorting, payment, routing).
| Component | Role |
|---|---|
| Strategy | Algorithm interface |
| ConcreteStrategy | Specific algorithm |
| Context | Uses a strategy |
When to use: Use for undo/redo, task queuing, macro recording.
| Component | Role |
|---|---|
| Command | Interface with execute() |
| ConcreteCommand | Binds receiver to action |
| Invoker | Triggers command |
| Receiver | Performs the work |
When to use: Use when multiple classes share the same algorithm but differ in specific steps.
| Component | Role |
|---|---|
| AbstractClass | Template with hook methods |
| ConcreteClass | Overrides specific steps |
When to use: Use for middleware pipelines, event bubbling, approval workflows.
| Component | Role |
|---|---|
| Handler | Interface with next handler |
| ConcreteHandler | Handles or passes along |
When to use: Use when an object has many conditional behaviours that depend on its state.
| Component | Role |
|---|---|
| Context | Maintains current state |
| State | Interface for behaviours |
| ConcreteState | State-specific behaviour |
When to use: Use when many objects communicate in complex ways (chat rooms, UI components).
| Component | Role |
|---|---|
| Mediator | Coordination interface |
| ConcreteMediator | Implements coordination |
| Colleague | Communicates via mediator |
When to use: Use when you need to perform many unrelated operations on an object structure.
| Component | Role |
|---|---|
| Visitor | Declares visit methods |
| ConcreteVisitor | Implements operations |
| Element | Accepts visitors |
- Observer — notify dependents when state changes
- Strategy — swap algorithms at runtime
- Command — encapsulate requests as objects (undo/redo)
- Template Method — define algorithm skeleton, defer steps
- Chain of Responsibility — pass request along handler chain
- State — change behaviour when state changes
- Mediator — centralise complex communication
- Visitor — add operations without modifying classes
Object Creation
- Singleton — one global instance
- Factory Method — subclass decides
- Abstract Factory — product families
- Builder — step-by-step
- Prototype — clone instances
Object Composition
- Adapter — interface conversion
- Bridge — abstraction split
- Composite — tree structures
- Decorator — dynamic behaviour
- Facade — simple interface
- Flyweight — memory sharing
- Proxy — access control
Communication
- Observer — event notification
- Strategy — swap algorithms
- Command — encapsulate requests
- Template Method — algorithm skeleton
- Chain of Resp. — handler pipeline
- State — state-based behaviour
- Mediator — central coordination
- Visitor — add operations