Choosing Behavioral Patterns - Learning Module

Loading content...

0/246

Behavioral Pattern Comparison

The Selection Challenge

Behavioral design patterns—all eleven of them in the classical Gang of Four catalog—address object interaction and responsibility distribution. Yet the sheer number of patterns creates a paradox: knowing the patterns is far easier than knowing when to apply each one.

Consider this common scenario: you're designing a system where objects need to respond to state changes. Should you use Observer for publisher-subscriber semantics? Mediator to centralize communication? Chain of Responsibility for sequential handling? Or perhaps State if the changes relate to object behavior transitions?

The difference between a journeyman developer and a senior architect often lies not in pattern knowledge, but in pattern selection intuition—the ability to instantly recognize which pattern best fits a given problem space. This intuition isn't magic; it's built through systematic comparison and deliberate practice.

What You Will Master

By the end of this page, you will understand the core purpose, participants, and distinguishing characteristics of every behavioral pattern. You'll develop a mental model for comparing patterns along multiple dimensions and recognize the subtle distinctions that determine optimal selection.

The Behavioral Pattern Landscape

Before diving into detailed comparisons, let's establish the complete landscape of behavioral patterns. The Gang of Four defined eleven behavioral patterns, each addressing a specific aspect of how objects communicate and distribute responsibilities.

The Classification Framework:

Behavioral patterns can be organized along several dimensions:

Class vs Object Patterns: Whether the pattern uses inheritance (class) or composition (object)
Object Creation vs Communication: Whether the pattern affects object lifecycles or message passing
Coupling Reduction: How the pattern reduces dependencies between objects
Responsibility Distribution: How the pattern allocates work among participants

Complete Behavioral Pattern Catalog
Pattern	Classification	Primary Purpose	Key Insight
Chain of Responsibility	Object	Pass requests along a chain of handlers	Decouple sender from receivers
Command	Object	Encapsulate requests as objects	Enable undo, queue, and log operations
Interpreter	Class	Define grammar representations	Implement domain-specific languages
Iterator	Object	Sequential access without exposing internals	Unify collection traversal
Mediator	Object	Centralize complex communications	Replace many-to-many with hub-and-spoke
Memento	Object	Capture and restore object state	Externalize state without breaking encapsulation
Null Object	Object	Provide default no-op behavior	Eliminate null checks throughout code
Observer	Object	Notify dependents of state changes	Enable loose-coupled event distribution
State	Object	Change behavior when state changes	Eliminate conditional state logic
Strategy	Object	Define interchangeable algorithms	Enable algorithm selection at runtime
Template Method	Class	Define algorithm skeleton with customizable steps	Invert control between framework and application
Visitor	Object	Add operations without modifying classes	Separate algorithms from object structures

The Null Object Pattern

While not part of the original Gang of Four catalog, the Null Object pattern is widely recognized as an essential behavioral pattern. It addresses the ubiquitous problem of null reference handling and fits naturally within the behavioral pattern family.

Understanding Pattern Intent

Each behavioral pattern exists because the Gang of Four identified a recurring design problem that required a structured solution. Understanding the precise intent of each pattern is foundational to accurate selection.

The Intent Triangle:

Every pattern's intent can be decomposed into three components:

The Problem: What design challenge does this pattern address?
The Forces: What constraints or competing concerns must be balanced?
The Resolution: How does the pattern resolve these forces?

Pattern Intent Breakdown

•Chain of Responsibility — Intent: Avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
•Command — Intent: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
•Interpreter — Intent: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
•Iterator — Intent: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
•Mediator — Intent: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly.
•Memento — Intent: Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
•Null Object — Intent: Provide an object that substitutes for the lack of an object of a given type and implements the expected interface with do-nothing behavior.
•Observer — Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
•State — Intent: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
•Strategy — Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
•Template Method — Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps without changing the algorithm's structure.
•Visitor — Intent: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Memorizing Intent vs Understanding Intent:

Rote memorization of these intents is insufficient for pattern selection. True understanding requires recognizing the problem shape that each intent addresses:

If you need to decouple senders from receivers → Chain of Responsibility
If you need to treat operations as data → Command
If you need to implement DSLs or expression evaluation → Interpreter
If you need to traverse collections uniformly → Iterator
If you need to reduce many-to-many object coupling → Mediator
If you need to save/restore state without exposing internals → Memento
If you need to eliminate null checks → Null Object
If you need to broadcast state changes → Observer
If you need to change behavior based on internal state → State
If you need to swap algorithms at runtime → Strategy
If you need to define algorithm structure with customizable steps → Template Method
If you need to add operations to class hierarchies without modification → Visitor

Structural Comparison

Beyond intent, behavioral patterns can be compared by their structural characteristics—the participants involved and how they collaborate. This structural analysis reveals deeper similarities and differences.

Pattern Participants and Relationships
Pattern	Core Participants	Key Relationship	Communication Direction
Chain of Responsibility	Handler, ConcreteHandler, Client	Handlers form a linked chain	Unidirectional (along chain)
Command	Command, ConcreteCommand, Invoker, Receiver	Invoker holds Command; Command knows Receiver	Decoupled via Command object
Interpreter	AbstractExpression, TerminalExpression, NonterminalExpression, Context	Expressions form tree structure	Recursive evaluation
Iterator	Iterator, ConcreteIterator, Aggregate, ConcreteAggregate	Iterator traverses Aggregate	Sequential access
Mediator	Mediator, ConcreteMediator, Colleague	Colleagues communicate via Mediator only	Hub-and-spoke (star topology)
Memento	Originator, Memento, Caretaker	Caretaker holds Mementos; Originator creates/restores	State snapshot and restore
Null Object	AbstractObject, RealObject, NullObject	NullObject provides default behavior	Polymorphic substitution
Observer	Subject, ConcreteSubject, Observer, ConcreteObserver	Subject notifies Observers	One-to-many broadcast
State	Context, State, ConcreteState	Context delegates to current State	Behavior delegation
Strategy	Context, Strategy, ConcreteStrategy	Context delegates to Strategy	Algorithm delegation
Template Method	AbstractClass, ConcreteClass	Subclass overrides hook methods	Inheritance-based customization
Visitor	Visitor, ConcreteVisitor, Element, ConcreteElement, ObjectStructure	Elements accept Visitors; Visitors visit Elements	Double dispatch

Structural Similarities to Notice

Notice how Strategy and State share nearly identical structures—both have a Context that delegates to an abstract interface with concrete implementations. The difference is semantic: Strategy changes algorithms while State changes object behavior based on internal state. Similarly, Command and Memento both encapsulate something as an object, but Command encapsulates requests while Memento encapsulates state.

Class-Based vs Object-Based Patterns:

Two behavioral patterns rely primarily on inheritance (class patterns):

Template Method: Uses inheritance to vary parts of an algorithm
Interpreter: Uses inheritance to represent grammar rules

The remaining nine patterns rely on object composition:

They achieve flexibility by composing objects at runtime
They follow the principle of "favor composition over inheritance"
They support more dynamic behavior changes

The Frequently Confused Pairs

Certain behavioral patterns are frequently confused with each other due to superficial similarities. Mastering the distinctions between these commonly confused pairs is essential for accurate pattern selection.

Strategy vs State: The Structure Twins

These patterns have nearly identical class diagrams, making them the most frequently confused pair. The distinction lies entirely in intent and usage semantics.

Strategy Pattern

•Client explicitly selects the algorithm
•Strategy objects are typically stateless
•Strategies don't know about each other
•Context behavior is consistent; only the algorithm varies
•Example: Sorting algorithm selection (quicksort, mergesort, heapsort)

State Pattern

•State transitions happen internally
•State objects often maintain context reference
•States know about valid transitions
•Context behavior changes based on state
•Example: Order lifecycle (pending → processing → shipped → delivered)

The Decision Heuristic

Ask: 'Who decides when to switch?' If the client decides → Strategy. If the object itself decides based on its internal logic → State.

Multi-Dimensional Comparison Matrix

To facilitate systematic pattern comparison, we can evaluate all behavioral patterns across multiple dimensions. This matrix provides a quick reference for pattern selection based on specific requirements.

Coupling and Communication Characteristics
Pattern	Sender-Receiver Coupling	Communication Type	Knowledge Required
Chain of Responsibility	Very Low (sender knows nothing)	Sequential request passing	Handler interface only
Command	Low (via command object)	Request encapsulation	Command interface only
Interpreter	Medium (expression tree)	Recursive interpretation	Grammar structure
Iterator	Low (via iterator)	Sequential access	Iterator interface only
Mediator	Low-Medium (via mediator)	Centralized coordination	Colleague and mediator interfaces
Memento	Low (via memento)	State capture/restore	Memento interface only
Null Object	None (transparent)	Polymorphic substitution	None (uses existing interface)
Observer	Low (subscription)	One-to-many broadcast	Observer interface only
State	Medium (context-state)	Behavior delegation	State interface and transitions
Strategy	Low (via strategy)	Algorithm delegation	Strategy interface only
Template Method	High (inheritance)	Inheritance-based hook calls	Base class structure
Visitor	Medium-High (double dispatch)	Operation application	Element hierarchy

Flexibility and Extensibility Characteristics
Pattern	Runtime Flexibility	Extension Mechanism	Open/Closed Compliance
Chain of Responsibility	High (chain configurable)	Add new handlers	Excellent
Command	High (commands composable)	Add new commands	Excellent
Interpreter	Medium (grammar fixed)	Add new expressions	Good for expressions
Iterator	Medium (traversal fixed)	Add new iterators or aggregates	Good
Mediator	Medium (mediator central)	Modify mediator logic	Moderate (mediator concentration)
Memento	High (state snapshots)	Add new state types	Excellent
Null Object	High (drop-in replacement)	Use existing interface	Excellent
Observer	High (dynamic subscription)	Add new observers	Excellent
State	High (runtime transitions)	Add new states	Excellent
Strategy	High (runtime swappable)	Add new strategies	Excellent
Template Method	Low (inheritance bound)	Subclass and override	Moderate (requires subclassing)
Visitor	High for operations	Add new visitors	Excellent for operations; poor for elements

The Visitor Paradox

Visitor exemplifies a classic Open/Closed tradeoff: it makes adding new operations trivial (open for extension) while making adding new element types difficult (requires modifying all visitors). This is the reverse of the typical class hierarchy tradeoff. Choose Visitor when operations change frequently but element types are stable.

When Patterns Overlap

Behavioral patterns don't exist in isolation. Understanding where patterns overlap—and where they don't—helps you make nuanced selection decisions.

The Overlap Spectrum:

Some patterns address similar problem spaces but from different angles:

Overlapping Pattern Domains

•Object Communication: Observer, Mediator, and Chain of Responsibility all address how objects communicate. Observer is best for broadcast notifications, Mediator for complex bidirectional coordination, and Chain of Responsibility for sequential request handling.
•Algorithm Encapsulation: Strategy, Command, and Template Method all address algorithm/behavior encapsulation. Strategy swaps entire algorithms, Command encapsulates specific actions, and Template Method varies steps within a fixed structure.
•State Management: State, Memento, and Command all relate to state. State manages behavioral changes from state transitions, Memento captures and restores state snapshots, and Command can support undo/redo through state-aware operations.
•Request Processing: Chain of Responsibility, Command, and Interpreter all process requests. Chain of Responsibility routes requests, Command encapsulates them, and Interpreter evaluates domain-specific expressions.
•Traversal and Access: Iterator and Visitor both traverse object structures. Iterator provides sequential element access, while Visitor applies operations during traversal.

Distinguishing by Primary Concern:

When patterns overlap, determine which primary concern dominates your requirements:

Concern	Primary Pattern	Secondary Patterns
Decoupling sender from receiver	Chain of Responsibility	Command, Observer
Reifying actions as objects	Command	Strategy, Memento
Broadcasting state changes	Observer	Mediator
Centralizing control logic	Mediator	Observer
Capturing state without exposure	Memento	Command
Handling absence gracefully	Null Object	Strategy, State
Changing behavior by state	State	Strategy
Choosing algorithms dynamically	Strategy	State, Template Method
Defining extensible operations	Visitor	Iterator
Fixed algorithm with hooks	Template Method	Strategy
Uniform collection access	Iterator	Visitor

Summary: Building Pattern Selection Intuition

We've covered the complete landscape of behavioral patterns, their intents, structures, and distinctions. Let's consolidate the key insights for pattern selection:

Key Takeaways

•Intent is paramount — Each pattern solves a specific problem. Understanding intent deeply is more valuable than memorizing structure.
•Structure reveals relationships — Similar structures (Strategy/State, Command/Memento) serve different purposes. Compare participants and collaborations.
•Commonly confused pairs require careful analysis — Strategy vs State, Observer vs Mediator, and Template Method vs Strategy are frequent confusion points. Use decision heuristics.
•Patterns exist on spectrums — Communication patterns, algorithm patterns, and state patterns each form related groups with overlapping applicability.
•Primary concern drives selection — When patterns overlap, identify your dominant requirement and choose the pattern that addresses it most directly.
•Class vs Object patterns matter — Template Method and Interpreter use inheritance; the rest use composition. This affects flexibility and testability.

What's Next:

With a solid foundation in pattern comparison, the next page provides a systematic decision tree for selecting behavioral patterns based on problem characteristics. This transforms comparison knowledge into an actionable selection process.

Page Complete

You now have a comprehensive understanding of how behavioral patterns compare across multiple dimensions. This foundation enables systematic pattern selection based on problem analysis rather than intuition alone.