Eleven patterns in eleven lessons: the catalog's largest family, and also its most confusable — half a dozen of its members share a diagram and are told apart only by intent. This lesson is the module's final map: the complete table, the five head-to-heads that resolve 90% of real-world doubts, a decision flowchart, the combinations that work as a team, and the review of what got installed in every corner of PideYa. When you finish it, the entire GoF catalog — creational, structural, and behavioral — will be in your toolbox.

1. The table of the eleven
2. The pairs everyone confuses, face to face
3. Decision guide
4. Frequent combinations
5. Module 4 on the PideYa map
6. Exercises and conclusion
7. Closing: the catalog is complete

The "reifies" column is no ornament: it's the module's summary. All eleven apply the same move — turning an aspect of behavior into an object — and are distinguished by what they turn.

Structural twins (a context delegating to an interface with variants); opposite intent:

Litmus test: if the delegated object replaces itself from within, it's State; if it's chosen from outside and the variants form no life cycle, it's Strategy.

Both encapsulate "code in an object":

Litmus test: look at the signature. If the method needs no arguments because the object already carries the complete request inside, it's Command; if it receives the data on each call, it's Strategy.

Both decouple communication:

Litmus test: does the notifier need someone to decide what happens next (Mediator), or just that whoever cares finds out (Observer)?

The inheritance/composition matchup:

Litmus test: do you need to hot-swap the variant or combine axes? Composition (Strategy). Fixed flow, few stable variants that share context? Template.

The cross-family matchup (promised in module 3): both are linked objects with the same interface that delegate to the next.

Litmus test: can some element legitimately cut the chain? Chain. Does everyone always contribute their layer? Decorator.

The question tree to orient yourself (like every guide: a compass, not a law — confirm afterwards against the corresponding head-to-head):

And the usual reminder, inherited from the scales lesson: the first valid option is none. An if, a direct call, or an enum are still the right answer when the symptom hasn't appeared.

Behavioral patterns work as a team better than any other family:

• Command + Memento: the robust-undo duo — inverse when it's symmetric and cheap, picture when the inverse lies. The ManagementPanel stacks commands; the difficult commands store mementos of their receiver.
• Observer + Mediator: the DispatchCenter can learn about the order's status changes as just another observer (transitionTo notifies) and direct the reaction as a mediator — broadcast to find out, protocol to act.
• Composite + Iterator + Visitor: the structures trio — Composite defines the menu's tree, Iterator traverses it without exposing it, Visitor adds operations without touching it. Three lessons, one menu.
• State + Observer: State authorizes the order's transitions; Observer broadcasts the ones that happen. Connected at a single point: transitionTo.
• Mediator + Strategy: the mediator orchestrates; its variable criteria (courier assignment) are injected strategies.
• Template Method + Strategy/Bridge: the fixed flow via inheritance, the hot-swappable axes via composition — Template Method's final exercise over the Notification classes.
• Chain + Command: commands can travel along the chain: the reified request looking for its handler.
• Interpreter + Visitor + Flyweight: over the rules AST — evaluate/print/optimize as different visitors, repeated terminals shared.

Note the constant: combinations are not designed "from the catalog" — they emerge because each pattern solves its symptom and the symptoms coexist in the same system.

The applied review, following an order's journey:

1. The order comes in → the validation chain (FraudHandler → DeliveryZoneHandler → StockHandler → MinimumAmountHandler) approves or rejects it, assembled in configuration and fired by the CheckoutFacade — Chain of Responsibility.
2. The delivery fee is calculated with the market's DeliveryFeeCalculation (distance, flat, free with a promotion), and the promotions are evaluated with the RuleExpressions marketing writes as text — Strategy and Interpreter.
3. The customer edits the cart with return points: Cart.Memento in the CartHistory — Memento.
4. The order lives its life cycle: OrderState authorizes each transition (CREATED → PAID → PREPARING → OUT_FOR_DELIVERY → DELIVERED / CANCELLED) — State — and each legal transition is broadcast to CustomerNotifier, CourierNotifier, KitchenMonitor, and StatsPanel — Observer, settling lesson 01-01's debt.
5. The restaurant manages from its panel with stackable, undoable, queueable Commands — Command.
6. Delivery is coordinated as a star: the DispatchCenter mediates between kitchen, orders, and couriers, with the swappable AssignmentStrategy — Mediator + Strategy.
7. The menu gets mined: traversed via Iterable<Dish> (search, streams) and operated on by MenuVisitor (export, allergens, audit) — Iterator and Visitor.
8. Every night, the closing reports follow ClosingReport's skeleton with their per-format steps — Template Method.

For each symptom, name the pattern (and, if you hesitated between two, which one you discarded and why):

1. "When the courier marks 'delivered', the customer app, billing, and metrics must react — and next month, the points program."
2. "The restaurant onboarding wizard has 6 screens with the same flow (validate → save → next) and different steps per screen."
3. "We want support to be able to revert the last 10 actions performed on an order, with an audit of who did what."
4. "The commission rate is calculated differently for premium, standard, and new restaurants, chosen by their contract."
5. "A price adjustment goes through: automatic validation → zone manager approval → finance approval if it exceeds 10%."

Without looking at the lessons: write the two "litmus tests" you would use with doubtful code between (a) State and Strategy, (b) Chain and Decorator. Then apply (a) to this case: TaxCalculator receives a TaxRegime in the constructor that never changes after construction and whose variants (GeneralRegime, SimplifiedRegime) don't know each other.

The team wants "undo" in the restaurant's menu editor too: every editor operation (rename section, change price, move dish) must be revertible, and so must "rebalance prices" (bulk, with rounding). Design the solution, naming the patterns you would combine and the role each one plays.

Solution 1:

1. Observer — variable, anonymous interested parties reacting to a change. (Discarded Mediator: nobody directs a protocol; each one reacts to its own concern.)
2. Template Method — fixed flow, variable steps per screen. (Discarded Strategy: the whole algorithm doesn't vary and no hot-swapping is needed.)
3. Command (+ Memento for the actions without a clean inverse) — reified requests with a history, undo, and auditing.
4. Strategy — alternative algorithms chosen from outside (the contract), with no transitions between them. (Discarded State: one regime doesn't "transition" to another through the operations.)
5. Chain of Responsibility — the request escalates through handlers that approve it or pass it on, with conditional links (finance only sometimes). (Discarded Decorator: there is cutting and conditions, not layers that always add.)

Solution 2: (a) does the delegated object replace itself from within, following a transition graph? → State; is it chosen by the outside and do the variants ignore each other? → Strategy. (b) can some element legitimately cut the chain? → Chain; does everyone always contribute their layer? → Decorator. The case: Strategy — the outside fixes it at construction, with no transitions and no mutual knowledge. (That it "never changes after construction" doesn't make it something else: the interchangeability is between context instances, not necessarily hot.)

Solution 3: Command as the backbone: each editor operation is a Command with execute()/undo(), stacked in an invoker with a stack (the ManagementPanel pattern). The simple, symmetric operations (renaming) undo by inverse; "rebalance prices" undoes by Memento — its execute() first captures a snapshot of the menu (a deep copy of the Composite, Prototype discipline) and its undo() restores it. Optional and coherent: confirmed changes are broadcast via Observer (the CatalogCacheProxy cache and the search engine want to know). Command provides the uniform framework; Memento steps in only where the inverse falls short — combining means assigning each pattern its symptom, not stacking them for fun.

You can now tell the eleven apart by intent, which is sometimes the only thing that separates them: you know what each one reifies, you have the five head-to-heads with their litmus tests, the decision tree to orient yourself, and the combinations that work because each piece attacks its own symptom. And PideYa stands as a living demonstration: from the chain that filters orders to the visitor that audits the menu, every pattern in the module is installed exactly where its pain called for it.

The 23 GoF patterns are now in your toolbox: the creational ones solved the objects' birth, the structural ones their anatomy, and the behavioral ones their conversations — who notifies whom, where the algorithms live, how what's done gets undone. Even the course's oldest debt, that changeStatus from the first lesson, was settled by Observer with State guarding the door.

But knowing the catalog is not knowing how to use it — it's the difference between owning the tools and being a good carpenter. The questions coming next are the hard ones: how do you choose a pattern for a real problem that doesn't arrive labeled? How do you refactor living code toward a pattern without breaking it? When does a well-applied pattern turn into an anti-pattern? Which patterns do Spring, the JDK, or your company's code actually use? That is the craft, and it's the whole module about to begin: see you in How to Select the Right Pattern.