Module 3: Behavioral Patterns

Primary texts: Head First Design Patterns and Design Patterns (GoF) Selective support: Refactoring (Fowler) for the "replace X with Y" moves that produce these patterns, Clean Code for readability, Good Code, Bad Code for judgment

This guide is the primary teacher. You do not need to read the source books front-to-back to complete this module. You do need to become operationally strong at recognizing when an axis of behavioral change deserves a pattern, implementing the pattern cleanly, and knowing when a simpler alternative is better.

---

Scope of This Module

Behavioral patterns are about how objects cooperate and change behavior at runtime. This module is not a naming catalog. It is where you learn to notice the shapes of change that pull code toward these patterns and to implement them without ceremony.

What it covers in depth:

• Strategy, Template Method, and when function references do the job instead
• Observer, its pitfalls (re-entrancy, ordering, leaks), and the pub/sub generalization
• Command, undo stacks, replayable histories, and queued execution
• State, the refactor path from switch chains to polymorphic states, and finite state machines
• Iterator and traversal decoupling
• Chain of Responsibility and the double-dispatch idea behind Visitor

What it deliberately does not cover here:

• Structural patterns (Module 4) and creational patterns beyond passing mention
• Reactive streams and backpressure as a full topic
• Large framework-specific event systems

If you can name a pattern but cannot explain what pressure it relieves and when it would be wrong, the module is not complete.

---

Before You Start

Answer closed-book before starting:

1. When is a switch on a type tag a hint that you are missing polymorphism?
2. What does "loose coupling between publisher and subscriber" buy you, concretely?
3. Why is "making an operation an object" useful beyond undo?
4. How is State different from Strategy, even though both delegate to a helper?
5. Why would a function reference be a better choice than a one-method Strategy class?

Diagnostic Interpretation

4-5 solid answers -- Ready for the full path.

2-3 solid answers -- Continue, but expect extra time in the Strategy and State clusters.

0-1 solid answers -- Revisit Module 1 cohesion/coupling and Module 2 refactor moves first.

---

What This Module Is For

Design patterns exist because the same shapes of change show up in real systems:

• "We keep adding new algorithms behind the same call."
• "Many things need to react when this value changes."
• "We need undo, queueing, or replay on these operations."
• "Behavior flips hard at certain lifecycle transitions."
• "Clients should not know how this collection is laid out."

Each pattern is a named, reusable solution to one of those shapes. Learning them is learning to read the pressure first, then to apply the minimal structural move that relieves it.

---

Concept Map

---

How To Use This Module

Work in order. Later clusters reuse habits from earlier ones (interface extraction, composition over inheritance, naming by intent).

Cluster 1: Strategy and Polymorphic Variation

Order	Concept	Type	Focus
1	Strategy: Encapsulating Interchangeable Algorithms	PRIMARY	Variation behind a single interface, composition over inheritance
2	Strategy vs Function References and Closures	PRIMARY	When OO is the right shape and when a function does
3	Template Method: Fixed Skeleton with Variable Steps	SUPPORTING	Inheritance-based variation, hooks, and when to prefer Strategy

Cluster mastery check: Can you tell when variation deserves a class versus a callable?

Cluster 2: Observer and Event Notification

Order	Concept	Type	Focus
4	Observer: Publishing State Changes Without Coupling	PRIMARY	Subject/observer, loose coupling, Open/Closed for subscribers
5	Observer Pitfalls: Re-entrancy, Ordering, Memory Leaks	PRIMARY	What goes wrong in production, and the defensive moves
6	Push vs Pull and the Pub/Sub Generalization	SUPPORTING	Who carries the data, topic routing, and event buses

Cluster mastery check: Can you add a new reactor without modifying the publisher, and can you explain one real failure mode?

Cluster 3: Command and Action Encapsulation

Order	Concept	Type	Focus
7	Command: Making Actions First-Class	PRIMARY	Invoker/command/receiver, parameterizing with operations
8	Undo/Redo and Command History	PRIMARY	History stacks, reversal, memento-style backups
9	Command Queues, Logging, and Replayable Systems	SUPPORTING	Queueing, serialization, and job/audit pipelines

Cluster mastery check: Can you draw a line between an invoker that triggers and a receiver that does, with a command object in between?

Cluster 4: State and Behavior-Switching Patterns

Order	Concept	Type	Focus
10	State Pattern: Polymorphic Transitions	PRIMARY	Context delegates to a state object; states pick their successor
11	State vs Switch/If Chains: The Refactor Path	PRIMARY	Moving from repeated conditionals to polymorphic states
12	Finite State Machine Modeling in Real Code	SUPPORTING	Transition tables, explicit events, and guard conditions

Cluster mastery check: Can you build an order lifecycle with three states without repeated switches?

Cluster 5: Traversal and Processing Patterns

Order	Concept	Type	Focus
13	Iterator: Decoupling Traversal from Container	PRIMARY	Collection interface, iterator state, generator equivalents
14	Chain of Responsibility: Passing Requests Through Handlers	PRIMARY	Handler chains, stop conditions, middleware shape
15	Visitor and the Double Dispatch Idea	SUPPORTING	Operations over heterogeneous trees, the type matrix

Cluster mastery check: Can you implement a logger chain and a tree iterator, and can you explain the one problem Visitor solves that Strategy cannot?

Then work the practice pages:

Order	Practice path	Focus
1	Strategy and Template Method Lab	Variation axis, interface extraction, when not to pattern
2	Observer and Pub/Sub Workshop	Subject/observer wiring, pitfalls, topic routing
3	State and Command Clinic	Lifecycle modeling, undo, command queues
4	Code Katas	Deliberate drills on each pattern

Use the Module Quiz after concept and practice. Use Reference and Selective Reading and Learning Resources only for targeted reinforcement.

---

Learning Objectives

By the end of this module you should be able to:

1. Identify the axis of change that makes Strategy the right pattern and distinguish it from Template Method.
2. Decide when a function reference or closure replaces a Strategy class cleanly.
3. Implement Observer with explicit subscription/unsubscription and defend against the common pitfalls.
4. Contrast push and pull and explain when a pub/sub bus beats direct Observer.
5. Implement Command with invoker, command, and receiver, and implement a simple undo stack.
6. Use commands to build a queue or replayable history.
7. Refactor a switch-heavy class into the State pattern and reason about transitions.
8. Model a real finite state machine explicitly with events and transitions.
9. Implement an Iterator and explain what the container's shape should not leak to clients.
10. Implement a Chain of Responsibility for logging or request validation and reason about stop conditions.
11. Explain Visitor and the double-dispatch problem it solves, and when to avoid it.

---

Outputs

• one refactor: a switch-heavy function converted to Strategy, with tests showing equivalent behavior
• one Observer implementation with documented guards against re-entrancy and leaks
• one Command-backed tool with undo and redo on at least five operations
• one State refactor: order or document lifecycle replacing two or more switch/if chains
• one Iterator over a non-trivial structure (tree or paginated source)
• one Chain of Responsibility: a logger or request pipeline with at least four handlers
• one pattern-selection memo: three situations where a pattern would be wrong and why
• one mistake log tagged with at least eight errors such as strategy for a one-off function, observer leak on disposal, command with hidden state, switch disguised as states, iterator that exposes internal cursor

---

Completion Standard

You have completed Module 3 when all of these are true:

• you pick patterns by pressure, not by name
• you can show, in your own code, the axis of change each pattern absorbs
• you can explain the cost of each pattern and the simpler alternative you rejected
• you can name at least one production failure mode per pattern
• you can refactor into and out of a pattern without breaking tests

If you can draw the diagram but cannot justify the pattern against a simpler option, the module is not complete.

---

Reading Policy

• Concept pages are the main path.
• Local book chunks are selective reinforcement, not a second syllabus.
• Read only if stuck means try the concept page, self-check, and kata first.
• Optional deep dive means extra nuance, not required progression.

---

Suggested Weekly Flow

Day	Work
1	Concepts 1-3 and Kata 1 (Strategy)
2	Concepts 4-6 and Kata 2 (Observer)
3	Concepts 7-9 and Kata 3 (Command with undo)
4	Concepts 10-12 and Kata 4 (State for order lifecycle)
5	Concepts 13-15 and Katas 5-6 (Iterator, Chain of Responsibility)
6	Practice pages 1-3, targeted book reinforcement
7	Practice page 4, quiz, mistake-log cleanup

---

Reference

If you need exact links into the local chunked books, use Reference and Selective Reading.

---

Rich Learning Pages

Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread