Deep Dive
low level designdesign patternsoop

Behavioral Patterns: How Objects Talk and Decide

The eleven behavioral patterns aren't eleven tricks — they're eleven answers to one question: when responsibility and communication are tangled inside a class, which one do you pull out, and where does it go? A map, not a re-teach.

·8 min read
Medium

Creational patterns decide who builds an object. Structural patterns decide how objects are wired together. Behavioral patterns pick up the last, hardest question: once the objects exist and are wired, who does what, and how do they talk?

That question hides in the one class every team is scared to touch — the OrderService, the GameLoop, the RequestHandler — because it has quietly absorbed three different jobs at once: it chooses the algorithm, it notifies everyone who cares, and it decides what happens next. Three unrelated responsibilities, one radioactive method.

Three responsibilities tangled in one method
java

The family, mapped

The Gang of Four grouped these eleven together because each one relocates a behavioral decision — an algorithm, a notification, a traversal, a transition — out of the class that was drowning in it. Here is the whole family and the one sentence that separates each from its neighbors.

Behavioralwho does what · how they talkVary the algorithmStrategy · Template MethodReify the requestCommand · Chain · InterpreterVary over lifecycleState · Memento · IteratorDecouple who talksObserver · MediatorAdd ops without editingVisitor
The eleven behavioral patterns split by what varies: the algorithm you run, the object you send, the state or traversal you're in, or the way a group of objects communicates.
  • Strategy → — Swap one interchangeable algorithm at runtime. The context holds a reference to a behavior and delegates; the caller picks which. (Already published — start here.)
  • Observer → — One-to-many change notification. A subject broadcasts a change; any number of observers react, and the subject never learns their names.
  • Command → — Turn a request into an object. Once a request is a value, you can queue it, log it, retry it, and undo() it.
  • State → — An object changes behavior when its internal state changes. A mini finite-state machine where each state is a class and can promote itself to the next.
  • Template Method → — Fix the skeleton of an algorithm, let subclasses fill the steps. The invariant order lives in the base class; the varying steps are overridden below.
  • Iterator → — Traverse a collection without exposing its internals. The client walks elements one by one, never touching the array, tree, or list underneath.
  • Mediator → — Objects talk through a hub instead of a mesh. Collaborators know the mediator, not each other, collapsing N×N wiring into N-to-1.
  • Memento → — Capture and restore an object’s state without breaking encapsulation. The snapshot is opaque to everyone but the object that made it — undo, checkpoints, save games.
  • Chain of Responsibility → — Pass a request along a chain until one handler takes it. Each link either handles the request or forwards it; the sender never knows which link answered.
  • Visitor → — Add operations to a class hierarchy without editing it. Double dispatch lets you bolt on new behavior across many types from the outside.
  • Interpreter → — Represent a grammar and evaluate sentences in it. Each grammar rule becomes a class; a tree of them evaluates an expression.

The confusions that cost interviews

Most behavioral patterns share a class diagram — an interface and some implementations — and differ entirely in intent. These four pairs are where nearly everyone slips.

Strategy
  • Encapsulates an interchangeable algorithm
  • The client picks which one
  • Strategies are peers, unaware of each other
  • Never promote themselves
State
  • Encapsulates a mode of behavior
  • The object's current state picks the behavior
  • States know their successors
  • A state can trigger the transition to the next

Strategy vs State — same shape, opposite driver. In Strategy the client chooses the algorithm and the pieces are peers; in State the object’s current mode chooses, and a state can promote itself (Pending → Shipped). The tell is self-promotion: if a piece decides what comes next, it’s State.

Observer vs Mediator — both cut direct coupling, but in different directions. Observer is one-to-many broadcast: one subject, many reactors, one-way. Mediator is many-to-many coordination: a hub sits between peers that would otherwise form a mesh, and it holds the interaction logic. Observer notifies; Mediator negotiates.

Command vs Strategy — both wrap behavior in an object. A Command reifies a request (“do this thing, and let me queue/log/undo it later”) and typically carries its own receiver and arguments. A Strategy reifies an algorithm (“here’s one of several ways to compute this”) that a context plugs in. “Do and undo” is Command; “compute, pick a how” is Strategy.

Chain of Responsibility vs Decorator — both build a linked pipeline of objects, and that’s why they blur. But a Decorator (structural) always forwards, adding behavior to every pass-through; a Chain link may stop — it handles the request and ends the walk. Decorator augments the whole call; Chain finds the one handler that answers.

Check yourself

References

Books

  • Gamma, Helm, Johnson, Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software, the Behavioral Patterns chapter.
  • Freeman, Robson, Sierra, Bates — Head First Design Patterns (2nd ed.), on Strategy, Observer, Command, State, and Template Method.
  • Martin Fowler — Refactoring: Improving the Design of Existing Code, “Replace Conditional with Polymorphism” and the moves that motivate Strategy, State, and Command.
Go Premium

Enjoyed this post?

Unlock every deep-dive on system design & distributed systems, and keep your reading streak alive.

View plans

Related Articles