Docs
22.1-Design-Patterns-Overview
21.4 Design Patterns
Overview
Design patterns are reusable solutions to common programming problems. This section covers essential JavaScript design patterns for building maintainable, scalable applications.
Pattern Categories
┌────────────────────────────────────────────────────────────────────────────┐
│ Design Pattern Categories │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ CREATIONAL STRUCTURAL BEHAVIORAL │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Singleton │ │ Adapter │ │ Observer │ │
│ │ Factory │ │ Decorator │ │ Strategy │ │
│ │ Builder │ │ Facade │ │ Command │ │
│ │ Prototype │ │ Proxy │ │ Iterator │ │
│ │ Module │ │ Composite │ │ Mediator │ │
│ └────────────┘ └────────────┘ │ State │ │
│ │ │ │ Chain │ │
│ ▼ ▼ └────────────┘ │
│ How objects How objects │ │
│ are created are composed ▼ │
│ How objects │
│ communicate │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Creational Patterns
Singleton Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Singleton Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Ensure a class has only one instance │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Singleton │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ - instance: Singleton │ │ │
│ │ │ + getInstance(): Singleton │ │ │
│ │ │ - constructor() │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Use Cases: │
│ • Configuration managers │
│ • Connection pools │
│ • Logging services │
│ • Application state │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Factory Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Factory Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Create objects without specifying exact class │
│ │
│ ┌──────────────┐ │
│ │ Factory │ │
│ │ createProduct│ │
│ └──────┬───────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ ProductA │ │ ProductB │ │ ProductC │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ Types: │
│ • Simple Factory - single method creates objects │
│ • Factory Method - subclasses decide instantiation │
│ • Abstract Factory - families of related objects │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Builder Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Builder Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Construct complex objects step by step │
│ │
│ new UserBuilder() │
│ .setName('John') ┌─────────────────┐ │
│ .setEmail('j@e.com') ───► │ Builder │ ───► User Object │
│ .setAge(25) │ (step by step) │ │
│ .build() └─────────────────┘ │
│ │
│ Benefits: │
│ • Clear construction process │
│ • Optional parameters handled elegantly │
│ • Immutable objects possible │
│ • Fluent interface (method chaining) │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Structural Patterns
Module Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Module Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Encapsulate related code with public/private members │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Module │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Private Scope (Closure) │ │ │
│ │ │ ├── privateVar │ │ │
│ │ │ └── privateMethod() │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Public API (Returned Object) │ │ │
│ │ │ ├── publicVar │ │ │
│ │ │ └── publicMethod() │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Modern: ES Modules (import/export) provide native module support │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Decorator Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Decorator Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Add behavior to objects dynamically │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Coffee │────►│ MilkDecorator│────►│SugarDecorator│ │
│ │ $5.00 │ │ +$0.50 │ │ +$0.25 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ Total: $5.75 │
│ │
│ In JavaScript: │
│ • Function wrappers │
│ • Class decorators (Stage 3) │
│ • Higher-order functions │
│ • Proxy objects │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Proxy Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Proxy Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Control access to an object │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Client │─────►│ Proxy │─────►│ Target │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ • Validation │ │
│ │ • Caching │ │
│ │ • Lazy loading │ │
│ │ • Logging │ │
│ │ • Access control │ │
│ └────────────────────────┘ │
│ │
│ JavaScript Proxy API: │
│ const proxy = new Proxy(target, { │
│ get(target, prop) { ... }, │
│ set(target, prop, value) { ... } │
│ }); │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Facade Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Facade Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Provide simplified interface to complex subsystem │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ Facade │ │
│ │ (Simple Interface) │ │
│ └─────────────────────────────┬──────────────────────────────────┘ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Subsystem A │ │ Subsystem B │ │ Subsystem C │ │
│ │ (Complex) │ │ (Complex) │ │ (Complex) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ Example: jQuery's $() is a facade over DOM APIs │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Behavioral Patterns
Observer Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Observer Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Define one-to-many dependency for state updates │
│ │
│ ┌──────────────┐ │
│ │ Subject │ │
│ │ (Publisher) │ │
│ └──────┬───────┘ │
│ │ notify() │
│ ┌────────────┼────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Observer1 │ │ Observer2 │ │ Observer3 │ │
│ │ update() │ │ update() │ │ update() │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ JavaScript Implementations: │
│ • EventEmitter (Node.js) │
│ • addEventListener (DOM) │
│ • RxJS Observables │
│ • Custom pub/sub systems │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Strategy Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Strategy Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Define family of algorithms, make them interchangeable │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Context │ │
│ │ setStrategy(strategy) │ │
│ │ executeStrategy() │ │
│ └───────────────────────────┬──────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────┐ │
│ │ Strategy (interface) │ │
│ │ execute() │ │
│ └──────────┬───────────────┘ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ StrategyA │ │ StrategyB │ │ StrategyC │ │
│ │ execute() │ │ execute() │ │ execute() │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Example: Different sorting algorithms, payment methods │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Command Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Command Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Encapsulate requests as objects │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ Invoker │────►│ Command │────►│Receiver │────►│ Action │ │
│ └─────────┘ │execute()│ │ │ │ │ │
│ │undo() │ └─────────┘ └──────────┘ │
│ └─────────┘ │
│ │
│ Benefits: │
│ • Undo/Redo support │
│ • Queuing and logging │
│ • Transactional behavior │
│ • Macro commands │
│ │
│ Example: Text editor commands, transactions │
│ │
└────────────────────────────────────────────────────────────────────────────┘
State Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ State Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Allow object to alter behavior when state changes │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Context │ │
│ │ currentState: State │ │
│ │ request() → state.handle() │ │
│ └───────────────────────────┬──────────────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ StateA │ │ StateB │ │ StateC │ │
│ │ handle() │ │ handle() │ │ handle() │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Example: Traffic light, order status, game characters │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Chain of Responsibility
┌────────────────────────────────────────────────────────────────────────────┐
│ Chain of Responsibility Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Pass request along chain until handled │
│ │
│ Request │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Handler 1 │───►│ Handler 2 │───►│ Handler 3 │ │
│ │ (can't │ │ (can't │ │ (HANDLES!) │ │
│ │ handle) │ │ handle) │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ JavaScript Examples: │
│ • Express middleware │
│ • DOM event bubbling │
│ • Promise chains │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Middleware Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Middleware Pattern │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Purpose: Process data through series of transformations │
│ │
│ Request ──► [Auth] ──► [Logger] ──► [Validator] ──► Handler │
│ │ │
│ Response ◄── [Compress] ◄── [Format] ◄──────────────────┘ │
│ │
│ Composition: │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ app.use(middleware1); │ │
│ │ app.use(middleware2); │ │
│ │ app.use(middleware3); │ │
│ │ │ │
│ │ // Each middleware calls next() to pass control │ │
│ │ function middleware(req, res, next) { │ │
│ │ // do work │ │
│ │ next(); │ │
│ │ } │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Pub/Sub vs Observer
┌────────────────────────────────────────────────────────────────────────────┐
│ Pub/Sub vs Observer │
├─────────────────────────────────┬──────────────────────────────────────────┤
│ Observer │ Pub/Sub │
├─────────────────────────────────┼──────────────────────────────────────────┤
│ │ │
│ Subject ◄──► Observers │ Publishers │
│ (Tight coupling) │ ▼ │
│ │ ┌─────────────────┐ │
│ Subject knows observers │ │ Event Channel │ │
│ Observers know subject │ │ (Message Bus) │ │
│ │ └─────────────────┘ │
│ │ ▼ │
│ Synchronous notifications │ Subscribers │
│ │ (Loose coupling) │
│ │ │
│ │ Publishers don't know subscribers │
│ │ Async possible │
│ │ │
└─────────────────────────────────┴──────────────────────────────────────────┘
When to Use Each Pattern
┌────────────────────────────────────────────────────────────────────────────┐
│ Pattern Selection Guide │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ Need Pattern │
│ ───────────────────────────────────── ─────────────────────── │
│ Single global instance Singleton │
│ Create objects without specifying type Factory │
│ Complex object construction Builder │
│ Add behavior without inheritance Decorator │
│ Control object access Proxy │
│ Simplify complex interface Facade │
│ Notify dependents of state changes Observer │
│ Switch algorithms at runtime Strategy │
│ Encapsulate actions as objects Command │
│ Object behavior depends on state State │
│ Sequential request handling Chain of Responsibility │
│ Process data through stages Middleware │
│ Loosely coupled event handling Pub/Sub │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Anti-Patterns to Avoid
┌────────────────────────────────────────────────────────────────────────────┐
│ Common Anti-Patterns │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ God Object Too many responsibilities in one class │
│ Spaghetti Code Tangled, unstructured code │
│ Golden Hammer Using same pattern for everything │
│ Copy-Paste Duplicating code instead of abstracting │
│ Premature Opt Optimizing before measuring │
│ Magic Numbers Hardcoded values without names │
│ Callback Hell Deeply nested callbacks │
│ Poltergeist Classes that just pass information │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Key Takeaways
- •Choose wisely - Patterns are tools, not rules
- •Don't force patterns - Use when they solve real problems
- •Combine patterns - Many work well together
- •Understand trade-offs - Each pattern has costs
- •Keep it simple - Start simple, add patterns as needed
- •Document usage - Make pattern usage clear to team
- •Adapt to JavaScript - Patterns may differ from classical OOP
Files in This Section
- •
README.md- This documentation - •
examples.js- Design pattern implementations - •
exercises.js- Pattern implementation exercises