Els creacionals van resoldre el naixement dels objectes de PideYa; els estructurals, la seva anatomia. Queda la pregunta que tancava el mòdul anterior, la més dinàmica de les tres: amb els objectes ja creats i ben connectats, com col·laboren en execució? Qui avisa qui quan una comanda canvia d'estat? Com es desfà una acció del panell del restaurant? On viu l'algorisme que decideix quin repartidor porta cada comanda? Els patrons de comportament responen a això: reparteixen responsabilitats entre objectes i organitzen la seva comunicació sense acoblar-los. Són la família més nombrosa del catàleg GoF —onze patrons— i aquesta lliçó n'és el mapa: quin problema comú ataquen, qui és qui, i quins mals concrets de PideYa està esperant cadascun.

1. El problema comú: col·laborar sense acoblar-se
2. Panorama dels onze patrons de comportament
3. Àmbit de classe i àmbit d'objecte
4. Símptomes a PideYa que cal un patró de comportament
5. Com llegirem cada patró en aquest mòdul
6. Exercicis i conclusió

Els creacionals responien a qui decideix quina classe s'instancia?; els estructurals, a com s'acoblen les peces?. Els patrons de comportament responen a dues preguntes entrellaçades:

• Assignació de responsabilitats: quin objecte ha de fer cada cosa? On viu un algorisme, qui guarda un estat, qui decideix una transició?
• Comunicació: com es parlen els objectes entre si per completar una tasca que cap no pot fer sol?

I l'enemic torna a ser el de sempre amb una tercera cara: l'acoblament, aquest cop a les converses. Al mòdul 2 l'acoblament s'esmunyia pel new; al 3, per les connexions estructurals; aquí s'esmuny per les crides:

• Un objecte que, per fer la seva feina, crida directament tots els interessats en ell (et sona Comanda.canviarEstat(...) de la primera lliçó del curs? Aquest mòdul salda aquell deute).
• Un algorisme cablejat dins de la classe que l'usa, impossible de canviar sense tocar-la.
• Un embull de condicionals (switch sobre estats, if sobre tipus) que es repeteix per tot el codi i creix amb cada cas nou.
• Objectes que es coneixen tots amb tots per coordinar-se: una malla on tocar-ne un arrossega tots els altres.
• Peticions que només existeixen com a crides efímeres: no es poden encuar, desfer, registrar ni reenviar.

L'estratègia de la família és sempre la mateixa, i ja la coneixes dels principis del mòdul 1: reïficar — convertir en objecte allò que abans era codi solt. Un algorisme esdevé un objecte (Strategy), una petició esdevé un objecte (Command), un estat esdevé un objecte (State), una foto del passat esdevé un objecte (Memento), un recorregut esdevé un objecte (Iterator). Un cop una cosa és un objecte, es pot intercanviar, injectar, encuar, desar i provar. És "programa contra interfícies" i "composició per sobre d'herència" aplicats a la conducta.

La foto completa del mòdul, cada patró en una línia. No la memoritzis ara: hi tornarem, ampliada i amb acaraments, a la comparativa final.

Onze són molts, així que convé agrupar-los mentalment per la conversa que organitzen:

• Encapsular allò variable: Strategy (un algorisme), State (un comportament dependent de l'estat), Command (una petició), Template Method (passos d'un algorisme), Interpreter (frases d'un llenguatge).
• Comunicar sense acoblar: Observer (un avisa molts que no coneix), Mediator (molts parlen a través d'un), Chain of Responsibility (la petició busca qui l'atengui).
• Treballar sobre estructures: Iterator (recórrer-les), Visitor (operar-hi), Memento (fotografiar-les i restaurar-les).

Com a les famílies anteriors, cada patró té un àmbit: de classe si la col·laboració es fixa amb herència en compilar, o d'objecte si s'estableix amb composició en execució. El recompte aquí és gairebé tan rotund com als estructurals: nou dels onze són d'àmbit d'objecte. Els dos d'àmbit de classe són:

• Template Method: l'esquelet de l'algorisme viu a la superclasse i les subclasses redefineixen passos heretant. És el patró d'herència per excel·lència.
• Interpreter: la gramàtica es plasma en una jerarquia de classes (una classe per regla), fixada en compilar.

Els altres nou componen: el context conté una estratègia, el subjecte conté observadors, l'invocador conté ordres... La parella Template Method / Strategy és l'acarament perfecte d'aquesta diferència —mateix problema, un el resol heretant i l'altre component— i el veurem cara a cara a la seva lliçó.

Com als mòduls anteriors: primer el símptoma, després el patró. Tots aquests mals existeixen avui a PideYa; cadascun té la seva lliçó:

Les onze lliçons de patró segueixen l'esquelet dels mòduls anteriors, perquè comparar-los sigui fàcil:

1. El problema a PideYa, amb el codi del primer intent (el dolent).
2. Estructura: intenció GoF i classDiagram mermaid amb els rols, com a la lliçó d'UML. En aquesta família hi afegirem sovint sequenceDiagram, perquè el que importa és la conversa en el temps, no només la foto estàtica.
3. Implementació Java completa, explicada pas a pas.
4. Variants rellevants de cada patró.
5. Quan usar-lo i quan no, amb l'honestedat de costos habitual.
6. Relació amb altres patrons: només mencions amb enllaç.
7. Errors comuns, exercicis amb solució i conclusió.

I seguim construint sobre allò construït: la carta Composite del mòdul 3 serà recorreguda per Iterator i visitada per Visitor; el Comanda.Builder del mòdul 2 fabricarà les comandes que Observer vigila i State governa; els Notificador decorats del mòdul 3 seran els receptors finals de les notificacions d'Observer; la FacanaCheckout invocarà la cadena de validació de Chain of Responsibility. Un sol sistema, moltes converses.

Per a cada situació nova de PideYa, digues quin patró de comportament de la taula sembla apuntar (n'hi ha prou d'aparellar el símptoma amb la intenció d'una línia):

1. Quan canvia el preu d'un plat, se n'han d'assabentar el cercador, la memòria cau del catàleg i l'històric de preus — i demà potser algú més.
2. El suport vol que una reclamació passi primer pel bot, després per un agent, després per un supervisor, i que cada nivell la resolgui o l'escali.
3. Volem provar dues maneres d'ordenar els restaurants a la home (per valoració, per proximitat) i triar-la per configuració.
4. En prémer "desar esborrany" d'una carta en edició, el restaurant vol poder tornar més tard exactament a aquell punt.

Aquest mòdul repeteix un truc: convertir en objecte una cosa que abans era codi solt. Indica quina cosa es converteix en objecte en cadascun d'aquests patrons: Strategy, Command, Memento, Iterator, State.

Solució 1:

1. Observer: un canvi, molts interessats desconeguts i variables.
2. Chain of Responsibility: la petició recorre manipuladors fins que un l'atén (o l'escala).
3. Strategy: algorismes alternatius i intercanviables rere una interfície comuna.
4. Memento: capturar l'estat per restaurar-lo després sense exposar les tripes de l'objecte.

Solució 2: Strategy reïfica un algorisme; Command, una petició (una crida amb els seus arguments); Memento, una instantània d'estat; Iterator, un recorregut (la posició i la lògica d'avanç); State, un estat i el seu comportament associat.

Ja tens el mapa de la família més nombrosa del catàleg: onze patrons que reparteixen responsabilitats i organitzen la comunicació entre objectes sense acoblar-los, gairebé tots mitjançant composició, i gairebé tots aplicant el mateix truc — reïficar la conducta per poder intercanviar-la, encuar-la, desar-la o repartir-la. Saps quin mal de PideYa espera cadascun, inclòs el més antic del curs: aquell canviarEstat de la primera lliçó que fa tres mòduls que espera Observer.

Però comencem per la porta d'entrada del negoci: cada comanda que arriba a PideYa ha de superar una cursa d'obstacles —és frau?, hi ha estoc?, repartim en aquella zona?, arriba a la quantia mínima?— i avui aquesta cursa és un mètode monolític que ningú no vol tocar. La convertirem en una cadena de baules independents i recombinables. Ens veiem a Chain of Responsibility.