Behavioral Patterns Overview

## The classification A **design pattern** is a named, reusable solution shape for a recurring design problem — not code you copy, but a structure of roles and responsibilities you re-implement in your own context. The 1994 *Design Patterns* book by Gamma, Helm, Johnson and Vlissides (the "Gang of Four", GoF) catalogued 23 patterns and grouped them along two axes: **purpose** (creational / structural / behavioral) and **scope** (class-level, via inheritance fixed at compile time, vs object-level, via composition assembled at runtime). ### Creational — "how do objects come into existence?" They decouple a caller from the concrete class it ends up using. - **Factory Method** — a subclass decides which concrete product to instantiate. - **Abstract Factory** — one object creates a whole family of related products. - **Builder** — assembles a complex object step by step. - **Prototype** — creates new objects by cloning an existing one. - **Singleton** — guarantees exactly one instance. ### Structural — "how are objects put together?" They describe composition: which object holds a reference to which, and what interface the composite presents. - **Adapter** — makes an incompatible interface usable. - **Decorator** — wraps an object to add behaviour transparently. - **Composite** — treats a tree of objects like a single object. - **Facade** — one simplified entry point over a subsystem. - **Proxy** — a stand-in controlling access (lazy, remote, protective). - **Bridge** — separates an abstraction from its implementation so both vary. - **Flyweight** — shares immutable state across many instances. ### Behavioral — "how do objects collaborate, and who is responsible?" This is the family in question. Behavioral patterns concern **control flow and responsibility assignment at runtime**: - **Observer** — one-to-many notification when state changes. - **Strategy** — interchangeable algorithms chosen by the client. - **Template Method** — a fixed algorithm skeleton with pluggable steps. - **Iterator** — sequential access to a collection without exposing its internals. - **Command** — a request packaged as an object (queue, log, undo). - **State** — behaviour changes when internal state changes; looks like class change. - **Chain of Responsibility** — pass a request along handlers until one handles it. - **Visitor** — add new operations over a fixed object structure via double dispatch. - **Mediator** — centralize many-to-many interaction in one coordinator. - **Memento** — capture and restore an object's internal state without breaking encapsulation. - **Interpreter** — represent a grammar and evaluate sentences in it. ## The common mechanism Nearly every behavioral pattern is a way of turning a **conditional or hardwired call into a polymorphic delegation**. A `switch` over payment types becomes Strategy. A `switch` over lifecycle status becomes State. A hardwired call to three downstream systems becomes Observer. An `if/else if` cascade of eligibility rules becomes Chain of Responsibility. The payoff is the Open/Closed Principle: adding a new case means adding a class, not editing an existing one. The cost is indirection — more small types, control flow you cannot read top-to-bottom, and a harder time answering "what actually runs?" from the source alone. ## Where the boundaries blur The categories are about **intent**, not code shape. Decorator (structural) and Chain of Responsibility (behavioral) both build a linked list of wrappers; Decorator's intent is that *every* wrapper contributes, the chain's intent is that *one* handler consumes. Strategy (behavioral) and Bridge (structural) both delegate to a swappable implementation object; Strategy varies an *algorithm* per call, Bridge varies an *implementation dimension* over the object's whole lifetime. State and Strategy are structurally identical — the difference is who chooses the delegate (client for Strategy, the object itself or its states for State). A strong answer acknowledges this rather than pretending the taxonomy is crisp. ## Edge cases and caveats - The GoF catalogue is not exhaustive or authoritative for modern systems; Null Object, Publish/Subscribe with a broker, and Dependency Injection are widely used and not in it. - In languages with first-class functions, several behavioral patterns collapse to a function value: Strategy is a lambda, Command is a closure, Observer is a list of callbacks, Template Method is a higher-order function. The *pattern* still exists — only its boilerplate disappears. - Naming a pattern is a communication tool. Its main value in an interview is that you can say "this is Strategy" and the other person immediately knows the roles, the extension point, and the trade-off.