The creational patterns solved the birth of PideYa's objects; the structural patterns, their anatomy. That leaves the question that closed the previous module, the most dynamic of the three: with the objects created and properly wired together, how do they collaborate at runtime? Who notifies whom when an order changes status? How do you undo an action in the restaurant panel? Where does the algorithm live that decides which courier takes each order? Behavioral patterns answer exactly this: they distribute responsibilities among objects and organize their communication without coupling them. They are the largest family in the GoF catalog — eleven patterns — and this lesson is your map: what shared problem they attack, who is who, and which concrete PideYa pains each one is waiting for.

1. The shared problem: collaborating without coupling
2. Overview of the eleven behavioral patterns
3. Class scope and object scope
4. Symptoms in PideYa that call for a behavioral pattern
5. How we will read each pattern in this module
6. Exercises and conclusion

Creational patterns answered who decides which class gets instantiated?; structural patterns, how do the pieces fit together?. Behavioral patterns answer two intertwined questions:

• Responsibility assignment: which object should do what? Where does an algorithm live, who holds a piece of state, who decides a transition?
• Communication: how do objects talk to each other to complete a task none of them can finish alone?

And the enemy is the usual one, showing its third face: coupling, this time in the conversations. In module 2, coupling sneaked in through new; in module 3, through structural connections; here it sneaks in through the calls:

• An object that, to do its job, directly calls every party interested in it (remember Order.changeStatus(...) from the very first lesson of the course? This module settles that debt).
• An algorithm hard-wired inside the class that uses it, impossible to change without touching the class.
• A tangle of conditionals (switch over statuses, if over types) repeated all over the codebase and growing with every new case.
• Objects that all know each other in order to coordinate: a mesh where touching one drags along the rest.
• Requests that only exist as ephemeral calls: they cannot be queued, undone, logged, or forwarded.

The family's strategy is always the same one, and you already know it from the principles in module 1: reify — turn into an object what used to be loose code. An algorithm becomes an object (Strategy), a request becomes an object (Command), a state becomes an object (State), a snapshot of the past becomes an object (Memento), a traversal becomes an object (Iterator). Once something is an object, it can be swapped, injected, queued, stored, and tested. It is "program to interfaces" and "composition over inheritance" applied to behavior.

The full picture of the module, each pattern in one line. Don't memorize it now: we will come back to it, expanded and with head-to-head matchups, in the final comparison.

Eleven is a lot, so it helps to group them mentally by the conversation they organize:

• Encapsulating what varies: Strategy (an algorithm), State (state-dependent behavior), Command (a request), Template Method (steps of an algorithm), Interpreter (sentences of a language).
• Communicating without coupling: Observer (one notifies many it doesn't know), Mediator (many talk through one), Chain of Responsibility (the request looks for someone to handle it).
• Working over structures: Iterator (traversing them), Visitor (operating on them), Memento (snapshotting and restoring them).

As in the previous families, each pattern has a scope: class scope if the collaboration is fixed through inheritance at compile time, or object scope if it is established through composition at runtime. The tally here is almost as lopsided as in the structural family: nine of the eleven are object-scoped. The two class-scoped ones are:

• Template Method: the algorithm's skeleton lives in the superclass and subclasses redefine steps by inheriting. It is the inheritance pattern par excellence.
• Interpreter: the grammar is captured as a class hierarchy (one class per rule), fixed at compile time.

The other nine compose: the context contains a strategy, the subject contains observers, the invoker contains commands... The Template Method / Strategy pair is the perfect head-to-head for this difference — same problem, one solves it by inheriting and the other by composing — and we will put them face to face in its lesson.

As in the previous modules: first the symptom, then the pattern. All of these pains exist in PideYa today; each one has its lesson:

The eleven pattern lessons follow the skeleton of the previous modules, so comparing them stays easy:

1. The problem in PideYa, with the code of the first attempt (the bad one).
2. Structure: the GoF intent and a mermaid classDiagram with the roles, as in the UML lesson. In this family we will often add a sequenceDiagram, because what matters is the conversation over time, not just the static snapshot.
3. Complete Java implementation, explained step by step.
4. Relevant variants of each pattern.
5. When to use it and when not to, with the usual honesty about costs.
6. Relationship with other patterns: mentions with links only.
7. Common mistakes, exercises with solutions, and a conclusion.

And we keep building on what we've built: the Composite menu from module 3 will be traversed by Iterator and visited by Visitor; the Order.Builder from module 2 will produce the orders that Observer watches and State governs; the decorated Notifier objects from module 3 will be the final receivers of Observer's notifications; the CheckoutFacade will invoke Chain of Responsibility's validation chain. One system, many conversations.

For each new PideYa situation, say which behavioral pattern from the table it seems to point to (matching the symptom against the one-line intent is enough):

1. When a dish's price changes, the search engine, the catalog cache, and the price history must all find out — and tomorrow maybe someone else too.
2. Support wants a complaint to go first through the bot, then through an agent, then through a supervisor, with each level either resolving it or escalating it.
3. We want to try two ways of ranking restaurants on the home page (by rating, by proximity) and pick one through configuration.
4. When the restaurant hits "save draft" on a menu being edited, it wants to be able to come back later to exactly that point.

This module repeats one trick: turning into an object something that used to be loose code. State what becomes an object in each of these patterns: Strategy, Command, Memento, Iterator, State.

Solution 1:

1. Observer: one change, many interested parties, unknown and variable.
2. Chain of Responsibility: the request travels through handlers until one handles it (or escalates it).
3. Strategy: alternative, interchangeable algorithms behind a common interface.
4. Memento: capture the state to restore it later without exposing the object's internals.

Solution 2: Strategy reifies an algorithm; Command, a request (a call together with its arguments); Memento, a state snapshot; Iterator, a traversal (the position and the advancing logic); State, a state and its associated behavior.

You now have the map of the largest family in the catalog: eleven patterns that distribute responsibilities and organize communication between objects without coupling them, almost all through composition, and almost all applying the same trick — reifying behavior so it can be swapped, queued, stored, or handed out. You know which PideYa pain awaits each one, including the oldest in the course: that changeStatus from the first lesson that has spent three modules waiting for Observer.

But we start at the business's front door: every order that reaches PideYa must survive an obstacle course — is it fraud? is there stock? do we deliver to that zone? does it reach the minimum amount? — and today that course is one monolithic method nobody wants to touch. We are going to turn it into a chain of independent, recombinable links. See you in Chain of Responsibility.