Behavioral Design Patterns
The problem
Objects need to communicate, coordinate, and change behavior at runtime in ways that hardcoded if/else chains handle poorly — behavioral patterns are named strategies for organizing communication and responsibility between objects that keep that coordination flexible instead of tangled.
Why now
Higher-order functions already showed that passing behavior itself as a value — not just data — unlocks flexible, swappable logic; behavioral patterns are that exact idea implemented with objects and polymorphism instead of first-class functions, for languages and situations where an object, not a bare function, is the natural unit of swappable behavior.
Mental model
Strategy makes an algorithm swappable by passing in a behavior-object instead of hardcoding logic — the object-oriented twin of passing a callback to a higher-order function. Observer lets objects subscribe to another object's changes without tight coupling. State lets an object change its entire behavior when its internal state changes, avoiding a sprawling switch statement. Each pattern replaces a rigid conditional with polymorphism doing the deciding instead.
Requires
- SOLID PrinciplesLow-Level Design
Behavioral patterns are concrete applications of Open/Closed (add new behavior without editing existing code) and Dependency Inversion (depend on a behavior abstraction, not a concrete implementation) — you need those principles as the 'why' before the patterns read as anything but arbitrary structure.
- Higher-Order FunctionsProgramming Fundamentals
Strategy, in particular, is the object-oriented version of passing a function as a value; recognizing that connection makes the pattern immediately intuitive instead of a new idea to learn from scratch.
Unlocks
Used in
- Strategy pattern for swappable algorithms (e.g. different sorting or pricing strategies)
- Observer pattern underlying event systems, pub/sub, and reactive UI frameworks
- State pattern for objects with distinct behavior per state (a TrafficLight, an order's lifecycle)
- Command pattern for undo/redo systems and queued or logged operations
Projects
- Implement a Strategy pattern for a payment system supporting CreditCard, PayPal, and Crypto payment strategies, swappable without modifying the checkout class
- Implement an Observer pattern where multiple UI components subscribe to and react to a single shared data source's changes
Examples
- A PricingStrategy interface with RegularPricing, SalePricing, and MemberPricing implementations lets checkout logic stay identical while the pricing algorithm varies
- A TrafficLight object using the State pattern delegates its next() behavior entirely to its current RedState/YellowState/GreenState object, avoiding a sprawling if/else chain
Resources
Mastery checklist
- I can implement a Strategy pattern for a swappable algorithm
- I can implement an Observer pattern connecting a subject to multiple independent observers
- I can implement a State pattern replacing a large conditional with polymorphic state objects
- I can explain the connection between the Strategy pattern and passing a function as a value