Behavioral Pattern Selector

Behavioral Pattern Selector

When to Use

You have identified that a problem is behavioral — it concerns how objects communicate, distribute responsibilities, or vary their actions — and need to pick the right one of the 11 GoF behavioral patterns. This skill is appropriate when:

• You have algorithms that vary across contexts and clients should swap them independently
• An object must change its behavior radically when its internal state changes
• You need to issue requests without knowing the receiver or the operation in advance
• Multiple objects are communicating in complex, entangled ways and need decoupling
• You need to traverse or operate on a collection without exposing its internals
• You want to add operations to a stable class hierarchy without modifying it
• You need to save and restore an object's internal state without breaking encapsulation
• You want to define a grammar for simple sentences and interpret them
• You are deciding among behavioral patterns and want an explicit trade-off comparison

Before starting, confirm:

• Is the problem genuinely behavioral (communication/algorithm), not creational (object construction) or structural (interface composition)? If unsure, invoke design-pattern-selector first for purpose classification.
• Do you have at least a rough description of what the system needs to do differently — even informally?

Context & Input Gathering

Required Context (must have before proceeding)

• Behavioral problem description: What interaction, communication, or algorithmic variability challenge are you solving? Even a rough description works — "objects notify each other in a tangled web" or "I have switch statements picking between algorithms."
• What varies or needs decoupling: Identify whether it's an algorithm, state-dependent behavior, communication protocol, or request handling that needs flexibility.

Observable Context (gather from environment)

• Existing codebase: If available, scan for behavioral smell signals — switch/if-else chains on type, tightly coupled event handlers, state-dependent conditionals, hard-coded request routing.
• Related patterns already in use: Check if creational or structural patterns are already applied — they constrain which behavioral patterns compose well.

Sufficiency

SUFFICIENT: problem description + what varies identified
PROCEED WITH DEFAULTS: rough problem description only (skill will help classify)
MUST ASK: no behavioral problem articulated at all

Process

Step 1: Set Up Tracking and Characterize the Problem

ACTION: Use TodoWrite to track progress, then capture the behavioral problem in structured form.

WHY: Behavioral patterns share surface similarities — Strategy, State, and Template Method all vary an algorithm, but for fundamentally different reasons. Without explicitly articulating what varies and why, you risk picking a pattern that fits the shape of the problem but not the intent. Forcing structured framing surfaces the distinction.

TodoWrite:
- [ ] Step 1: Characterize the behavioral problem
- [ ] Step 2: Apply Taxonomy 1 — What aspect to encapsulate
- [ ] Step 3: Apply Taxonomy 2 — Sender-receiver decoupling (if applicable)
- [ ] Step 4: Resolve ambiguous pairs with differentiating questions
- [ ] Step 5: Produce recommendation with trade-offs

Capture these elements from the user's description:

If more than one element is unclear, ask one targeted question and wait for a response before continuing.

Step 2: Apply Taxonomy 1 — What Aspect to Encapsulate

ACTION: Match the problem against the encapsulation taxonomy. Identify which aspect of the program is expected to change and therefore needs its own object.

WHY: The defining theme of behavioral patterns is encapsulating variation. Each pattern names the thing that changes and lifts it into a dedicated object. If you can identify what that thing is, you can identify the pattern — because the pattern is literally named for it. Skipping this step leads to pattern matching by feel rather than by structure.

Encapsulation taxonomy:

Three patterns that do not fit this taxonomy (they work at the class or communication level):

Output: Identify the encapsulated aspect and the candidate pattern(s) it points to. If the problem description mentions both an algorithm and state-driven behavior, or both communication and a protocol object, flag both candidates and proceed to Step 4.

Step 3: Apply Taxonomy 2 — Sender-Receiver Decoupling (If Applicable)

ACTION: If the problem involves decoupling who sends a request from who handles it, evaluate the four decoupling patterns against each other.

WHY: Command, Observer, Mediator, and Chain of Responsibility all decouple senders from receivers, but with very different structures and trade-offs. Choosing the wrong one produces either the right decoupling for the wrong granularity (Observer when you need Command) or centralized logic that makes the system harder to understand (Mediator when Observer's distributed model is sufficient). This taxonomy makes the choice explicit.

Apply only if the problem includes any of these:

• "The sender should not know who handles the request"
• "Multiple objects need to react to a change"
• "Objects are too tightly coupled to each other"
• "Requests should be queued, logged, or undone"

Decoupling comparison:

Decision rules:

• Need undo/redo, queuing, or logging of requests? → Command (the request is a first-class object)
• One object changes and an unknown number of others must react? → Observer (broadcast, data dependency)
• Many objects interact in complex ways and the interaction logic should live in one place? → Mediator (centralize the protocol)
• Multiple candidate handlers exist and the right one is determined at runtime, but any one is sufficient? → Chain of Responsibility (but add a fallback handler to prevent silent drops)

Output: If this taxonomy applies, add the appropriate decoupling pattern as a candidate or as a confirmation of the candidate from Taxonomy 1.

Step 4: Resolve Ambiguous Pattern Pairs

ACTION: If two or more candidates remain after Steps 2–3, apply the differentiating questions for the relevant pair.

WHY: Several behavioral patterns share structural similarities. Strategy and State have identical class diagrams. Template Method and Strategy both vary algorithms. Without asking the right differentiating question, you will correctly identify the problem category but pick the wrong pattern.

Pair: Strategy vs. State

Both encapsulate behavior that can be swapped at runtime via a context object. The difference is who initiates the swap and why:

Pair: Template Method vs. Strategy

Both vary an algorithm, but via opposite mechanisms:

Pair: Observer vs. Mediator

Both decouple objects from direct references, but in opposite directions:

Pair: Command vs. Chain of Responsibility

Both issue a request without the sender knowing the receiver, but via different mechanisms:

Output: A single confirmed pattern, or at most two if the problem genuinely requires both (e.g., Command + Chain of Responsibility is a valid composition — the chain uses Command objects as the request representation).

Step 5: Produce Recommendation with Trade-offs

ACTION: Deliver the recommendation in the format below. Include the taxonomy reasoning that led to it, the key trade-off, and the runner-up pattern with why it was not chosen.

WHY: A recommendation without reasoning is a guess. The user needs to understand the taxonomy path that produced the choice — both to validate it and to apply the pattern correctly. The trade-off section prevents misapplication in edge cases.

Recommendation format:

## Pattern Recommendation: [Pattern Name]

**Category:** Behavioral — [Class / Object] scope

**Encapsulation taxonomy:** [What aspect is being encapsulated as an object]
**Decoupling taxonomy:** [If applicable — which sender-receiver model applies]

**Why this pattern:** [1–2 sentences connecting the pattern's intent to the specific problem]

**What it enables:** [What becomes possible that wasn't before]

**Key trade-off:** [What complexity or constraint is introduced]

**Warning (if applicable):** [Chain of Responsibility: silent drop risk; Mediator: bottleneck risk; etc.]

**Alternative considered:** [Runner-up pattern] — [Why it was not chosen]

**Patterns to combine with:** [Any complementary patterns]

Common combinations:

• Chain of Responsibility + Command — chain uses Command objects so requests can be logged or replayed; Template Method defines handler dispatch logic
• Observer + Mediator — Observer for subject-observer notification; Mediator to coordinate the subjects themselves
• Strategy + Template Method — Template Method defines the algorithm skeleton; Strategy fills in variable steps via composition (evolution path when inheritance becomes limiting)
• Iterator + Visitor — Iterator traverses the aggregate; Visitor applies an operation to each element
• Command + Memento — Command executes operations; Memento provides state snapshots to support undo

Examples

Example 1: Order Processing with Multiple Tax Algorithms

Scenario: An e-commerce system computes tax differently depending on region (US federal, EU VAT, Canadian GST). The tax logic is embedded in the Order class as a large if/else block. A new region is coming and the team does not want to keep modifying Order.

Trigger: "We have different tax rules per region and the order class keeps getting bigger every time we add one."

Process:

• Step 2 (Taxonomy 1): What varies is the algorithm for tax computation. Clients (or configuration) choose which algorithm to apply. → Strategy
• Step 3 (Taxonomy 2): No sender-receiver decoupling concern — Order calculates tax directly.
• Step 4: Strategy vs. State? The variation is client-selected (region at order creation), not self-transitioning behavior. Confirmed: Strategy.

Output:

## Pattern Recommendation: Strategy

**Category:** Behavioral — Object scope

**Encapsulation taxonomy:** Algorithm (tax computation rule) is extracted into a TaxStrategy object

**Why this pattern:** Strategy replaces the if/else dispatch with a TaxStrategy
interface. Each region (USTaxStrategy, EUVATStrategy, CAGSTStrategy) is a
ConcreteStrategy. Order holds a reference and delegates to it.

**What it enables:** New regions are new TaxStrategy subclasses — Order is never
modified. Strategies can be tested independently.

**Key trade-off:** Clients must know which strategy to instantiate; this knowledge
must come from somewhere (configuration, factory). If strategy selection is itself
complex, pair with Abstract Factory.

**Alternative considered:** Template Method — would require subclassing Order for
each region (OrderForUS, OrderForEU), which tightly couples the algorithm variation
to the order lifecycle. Strategy via composition is cleaner.

**Patterns to combine with:** Abstract Factory (to instantiate the correct strategy
based on region configuration)

Example 2: UI Form with Enable/Disable Logic Across States

Scenario: A wizard dialog has three states: empty (all fields disabled except the first), partial (some fields enabled, Submit disabled), and complete (Submit enabled). Currently, every button-click handler contains the same conditional: "if state == X, enable Y, disable Z." The logic is duplicated across 12 event handlers.

Trigger: "Every event handler has to know what state the dialog is in. Adding a new state means touching all 12 handlers."

Process:

• Step 2 (Taxonomy 1): What varies is behavior per state — not a client-selected algorithm, but self-determined transitions. The dialog itself decides when to move from partial to complete. → State
• Step 4: Strategy vs. State? The dialog transitions itself (the "partial" state knows when to transition to "complete" based on field validation). No external client selects the behavior. Confirmed: State.

Output:

## Pattern Recommendation: State

**Category:** Behavioral — Object scope

**Encapsulation taxonomy:** State-dependent behavior — each wizard state (EmptyState,
PartialState, CompleteState) encapsulates its own enable/disable logic

**Why this pattern:** Each state object handles the event and applies the correct
enable/disable rules for that state. The wizard context delegates all event handling
to its current state object. Transitions (EmptyState → PartialState) are initiated by
the state objects themselves when conditions are met.

**What it enables:** Adding a new state is a new class — existing handlers are not
touched. The 12 duplicated conditionals collapse into the state objects that own them.

**Key trade-off:** State objects may need access to the context to initiate transitions,
introducing some coupling. The number of classes grows by one per state.

**Alternative considered:** Strategy — the behavior here is not client-selected; the
dialog self-transitions. Strategy would require the external caller to manage state
changes, which belongs inside the dialog lifecycle.

Example 3: Audit Log for Spreadsheet Operations

Scenario: A spreadsheet application must support unlimited undo/redo for cell edits, formula applications, and formatting changes. Operations may take several seconds. The team also wants a log of all executed operations for crash recovery.

Trigger: "We need full undo/redo and also want to replay operations from a log after a crash."

Process:

• Step 2 (Taxonomy 1): The request itself (each operation) needs to be a first-class object — stored, reversed, and replayed. → Command
• Step 3 (Taxonomy 2): Sender-receiver decoupling: the UI (invoker) must not know the cell/formula/formatting receiver details. Command is the binding object. 1:1 per operation. Confirmed: Command.
• Step 4: Command vs. Chain? The receiver is known at command-creation time (the specific cell being edited). No chain needed. Command confirmed.

Output:

## Pattern Recommendation: Command

**Category:** Behavioral — Object scope

**Encapsulation taxonomy:** Request (each operation) is encapsulated as a Command
object with Execute() and Unexecute() operations

**Decoupling taxonomy:** 1 invoker (toolbar/keyboard) : 1 receiver (cell/formula/formatter)
per command — invoker stays decoupled from receiver details

**Why this pattern:** Each operation (EditCellCommand, ApplyFormulaCommand,
FormatRangeCommand) is an object. Execute() applies it; Unexecute() reverses it.
The history list holds executed commands. Undo traverses it backward; redo forward.
Crash recovery replays the log by re-executing stored commands.

**What it enables:** Unlimited undo/redo with no special logic in the UI. Crash
recovery by replaying the command log. Macro recording by composing commands into
MacroCommands.

**Key trade-off:** Each unique operation requires a Command subclass. If operations
are highly varied (many receiver types), this produces many classes. Closures or
lambdas can replace subclasses in languages that support first-class functions.

**Alternative considered:** Memento — captures state snapshots for undo but stores
full state copies, which is expensive for large spreadsheets. Command stores only the
delta (what changed), which is far more efficient.

**Patterns to combine with:** Memento (for operations whose reversal cannot be
computed — store a snapshot as part of the command's undo data)

Key Principles

• Two taxonomies, not one. Behavioral patterns can be classified by what they encapsulate (algorithm, state, protocol, traversal) AND by how they decouple senders from receivers. Use both lenses — one narrows the candidate set, the other confirms the choice. WHY: Patterns that look similar under one taxonomy (Strategy vs State) are clearly different under the other.
• Strategy and State have identical structure but opposite intents. Strategy varies the algorithm while context stays the same. State varies the context's behavior when its internal state changes. If the "which object to delegate to" decision is made by the client, it's Strategy. If it's made by the context itself (state transitions), it's State. WHY: This is the single most confused pair in the behavioral catalog.
• Observer distributes, Mediator centralizes. Both decouple interacting objects. Observer promotes finer-grained, more reusable classes but makes communication flow harder to trace. Mediator makes flow explicit but can become a monolith. WHY: Choosing wrong creates either untraceable event spaghetti (Observer misuse) or a god-object mediator.
• Chain of Responsibility has no delivery guarantee. A request can fall off the end of the chain unhandled, silently. Always include a catch-all handler or an assertion that the chain is complete. WHY: Silent request drops are the hardest bugs to diagnose.

Reference Files

License

This skill is licensed under CC-BY-SA-4.0. Source: BookForge — Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.

Related BookForge Skills

Install related skills from ClawhHub:

• clawhub install bookforge-design-pattern-selector

Or install the full book set from GitHub: bookforge-skills