The 22 patterns every developer should know.
Originally documented by the Gang of Four in 1994, these patterns remain the shared vocabulary of professional software design. Each one is a proven solution to a recurring problem — not a recipe to copy, but a blueprint to understand and adapt.
What is a design pattern?
A design pattern is a general, reusable solution to a commonly occurring problem in software design. Patterns are not finished code — they're templates. Understanding them gives you a mental toolkit for recognising problems and communicating solutions with other developers using shared vocabulary like "use an Observer here" or "that's a Facade."
Creational Patterns
Object creation mechanisms that increase flexibility and reuse.
Factory Method
Define an interface for creating an object, but let subclasses decide which class to instantiate. Decouple object creation from usage so new types can be added without touching client code.
→Abstract Factory
Produce families of related objects without specifying their concrete classes. When your system needs multiple objects that belong together, Abstract Factory enforces that they always come from the same family.
→Builder
Construct complex objects step by step. Builder lets you produce different types and representations of an object using the same construction process — without telescoping constructors.
→Prototype
Clone existing objects without depending on their concrete classes. When creating a fresh object from scratch is expensive or complex, copy an existing one and tweak only what differs.
→Singleton
Ensure a class has exactly one instance and provide a global access point to it. Useful for shared resources like config managers, connection pools, and loggers — but treat it with caution.
→Structural Patterns
How to assemble objects into larger structures while keeping them flexible.
Adapter
Allow objects with incompatible interfaces to work together. Wrap an existing class with a new interface so legacy or third-party code fits into your system without modification.
→Bridge
Decouple abstraction from implementation so both can vary independently. Instead of a single hierarchy that explodes with every combination, Bridge uses composition to let two dimensions evolve on their own.
→Composite
Compose objects into tree structures and treat individual objects and compositions uniformly. Client code can work with a single leaf or an entire tree using the exact same interface.
→Decorator
Attach new behaviours to objects at runtime by wrapping them in decorator objects. A flexible alternative to subclassing — stack multiple wrappers to compose behaviour.
→Facade
Provide a simplified interface to a complex subsystem. A Facade hides the complexity of a library, framework, or cluster of classes behind a single, easy-to-use entry point.
→Flyweight
Share common state between many fine-grained objects to fit more into available memory. Split object state into intrinsic (shared) and extrinsic (context-dependent) parts to eliminate duplication.
→Proxy
Provide a substitute for another object. A proxy intercepts access to the real object, letting you perform actions before or after the request — caching, access control, logging, lazy loading.
→Behavioral Patterns
How objects communicate and distribute responsibilities.
Chain of Responsibility
Pass requests along a chain of handlers. Each handler decides to process the request or pass it to the next handler. Decouples senders from receivers and lets you dynamically configure the chain.
→Command
Turn a request into a standalone object. This lets you parameterize methods with different requests, delay execution, queue operations, and implement undoable actions.
→Iterator
Traverse elements of a collection without exposing its underlying representation. Whether the collection is an array, tree, graph, or custom structure, the iterator provides a uniform way to walk through it.
→Mediator
Reduce direct dependencies between objects by routing all communication through a central mediator. Objects no longer talk to each other directly — they talk to the mediator, which decides what to do.
→Memento
Save and restore an object's state without violating encapsulation. The Memento pattern lets you snapshot an object's internal state so you can roll it back later — the basis of undo/redo.
→Observer
Define a subscription mechanism so multiple objects are automatically notified when the object they're watching changes state. The foundation of event systems, reactive UIs, and pub/sub architectures.
→State
Let an object alter its behaviour when its internal state changes. The object appears to change its class. Instead of giant switch/if-else blocks, extract each state into its own class.
→Strategy
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it — swap sorting, routing, pricing, or compression at runtime.
→Template Method
Define the skeleton of an algorithm in a base class and let subclasses override specific steps without changing the algorithm's structure. The invariant part lives in one place; the variant parts are deferred to subclasses.
→Visitor
Separate an algorithm from the object structure it operates on. Add new operations to existing class hierarchies without modifying those classes — the visitor "visits" each element and does its work.
→