Vint-i-tres patrons són massa per abordar-los en desordre. Per això el Gang of Four els va organitzar en un mapa amb dos eixos —el propòsit del patró i el seu àmbit— que continua sent la manera estàndard de navegar pel catàleg. Aquesta lliçó és exactament això: el mapa del territori que recorreràs als mòduls 2, 3 i 4. Veuràs les tres famílies (creacionals, estructurals i de comportament), quina pregunta respon cadascuna, la taula completa dels 23 patrons amb el seu propòsit en una línia, i una menció a les famílies que van quedar fora del GoF i que visitarem al mòdul 6. No desenvoluparem cap patró individual: avui toca orientar-se, no excavar.

1. Els dos eixos de classificació del GoF
2. Primer eix: el propòsit (les tres famílies)
3. Els 23 patrons, família a família
4. Segon eix: l'àmbit (classe davant d'objecte)
5. Més enllà del GoF: altres famílies de patrons
6. El mapa com a itinerari del curs

El llibre Design Patterns classifica els seus 23 patrons amb dos criteris ortogonals:

• Propòsit (purpose): quin tipus de problema resol el patró? Dona lloc a les tres famílies: creacionals (com es creen els objectes), estructurals (com es componen) i de comportament (com col·laboren i es reparteixen responsabilitats).
• Àmbit (scope): el patró opera sobre classes (relacions fixades en compilació, via herència) o sobre objectes (relacions establertes en execució, via composició)?

El primer eix és el que tothom fa servir per parlar de patrons i el que estructura aquest curs; el segon és més subtil però molt revelador, i el veurem a la secció 4.

Una intuïció útil per recordar les tres famílies amb PideYa: pensa en el cicle de vida dels objectes d'un sistema. Primer cal crear-los (qui fa el new de la passarel·la de pagament adequada?), després organitzar-los en estructures majors (com es munta un menú que conté plats i altres menús?), i finalment fer-los col·laborar (com s'assabenta el repartidor que la comanda ha canviat d'estat?). Creació → estructura → comportament.

Pregunta que responen: com crear objectes sense que el codi quedi acoblat a les classes concretes que instancia, i com controlar quantes instàncies existeixen i com es munten les complexes?

Com vam veure en estudiar els principis de disseny, el new és el punt on inevitablement s'anomena una classe concreta. Els creacionals existeixen per aïllar i centralitzar aquests punts, de manera que la resta del sistema programi contra interfícies. A PideYa, són els patrons que respondran a "qui decideix si el pagament es processa amb la passarel·la de targeta o amb PayPal?" o "com es construeix una comanda amb línies, descomptes, adreça i propina sense un constructor de deu paràmetres?".

Pregunta que responen: com combinar classes i objectes en estructures majors que continuïn sent flexibles i eficients?

Són els patrons de la composició: embolcallar un objecte per afegir-li alguna cosa, adaptar una interfície aliena a la que el teu codi espera, tractar igual un element i un grup d'elements, o donar una façana simple a un subsistema enrevessat. A PideYa apareixeran quan integrem l'API d'un proveïdor extern de pagaments que no encaixa amb les nostres interfícies, o quan modelem cartes que contenen seccions que contenen plats.

Pregunta que responen: com repartir responsabilitats entre objectes i organitzar la comunicació entre ells perquè cadascun faci la seva feina sense acoblar-se a la resta?

És la família més nombrosa, perquè la col·laboració és el més difícil de dissenyar. Aquí viuen els patrons que resolen el problema de les notificacions de Comanda que vam veure a la primera lliçó, els que modelen el cicle d'estats d'una comanda (rebuda → en preparació → en repartiment → lliurada) i els que permeten intercanviar algorismes (estratègies de càlcul de despeses d'enviament) en temps d'execució.

Aquí tens el catàleg complet. No intentis memoritzar-lo avui: fes-lo servir com un índex al qual tornar. Cada patró té la seva lliçó pròpia als mòduls 2–4.

Recompte: 5 + 7 + 11 = 23. Com a referència d'importància pràctica: no tots pesen igual en el dia a dia. Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Observer, Strategy, Template Method i Command apareixen constantment; Interpreter o Flyweight són molt més ocasionals. A les lliçons de cada patró i a les comparatives de tancament de cada mòdul (02-07, 03-09, 04-13) matisarem aquest pes relatiu.

El segon criteri del GoF pregunta com estableix el patró les seves relacions:

• Àmbit de classe: la relació clau es fixa mitjançant herència, en temps de compilació. Un cop compilat, el comportament està decidit.
• Àmbit d'objecte: la relació clau s'estableix mitjançant composició: referències entre objectes que es poden canviar en temps d'execució.

Dues observacions valuoses d'aquesta taula:

1. La immensa majoria de patrons són d'àmbit d'objecte. És la màxima "afavoreix la composició per sobre de l'herència" feta estadística: de 23 patrons, només un grapat es recolza en l'herència com a mecanisme central.
2. Hi ha parelles de patrons que resolen problemes semblants, un per classe i l'altre per objecte (ho veuràs, per exemple, entre Template Method i Strategy, o entre les dues variants d'Adapter). Comprendre l'eix d'àmbit et donarà el criteri per triar: l'herència és més simple però rígida; la composició, més flexible però amb més peces.

El mapa del GoF cobreix el disseny de classes i objectes dins d'una aplicació orientada a objectes. Com vam veure a la lliçó d'història, la comunitat va continuar collint patrons en altres nivells. Les famílies que convé tenir al radar:

• Patrons arquitectònics: decideixen la forma global del sistema, no d'unes classes (capes, MVC, microkernel, broker...). Operen a una escala major que el GoF.
• Patrons de concurrència: coordinen fils i recursos compartits (productor-consumidor, thread pool, reactor...).
• Patrons d'empresa i integració: persistència, transaccions i missatgeria entre sistemes (Repository, Unit of Work, cues i canals...).
• Patrons de microserveis i sistemes distribuïts: resiliència i coordinació entre serveis remots (API Gateway, Circuit Breaker, Saga...).

Totes aquestes famílies es tracten al mòdul 6 (arquitectures modernes, microserveis, sistemes distribuïts i concurrència); aquí n'hi ha prou que situïs cadascuna a la seva escala:

Aquesta classificació no és només teoria: és literalment l'índex del que ve. El teu itinerari:

Cada mòdul de patrons segueix a més el mateix ritme: una introducció a la família, una lliçó per patró (amb el problema plantejat a PideYa) i una comparativa final per triar entre patrons semblants. L'ordre creacionals → estructurals → de comportament no és casual: replica el cicle natural crear → compondre → col·laborar, i cada família es recolza en les anteriors.

• Intentar memoritzar els 23 de cop. És inútil i desmoralitzador. Avui només necessites les tres preguntes de família (creació? estructura? col·laboració?) i saber que la taula existeix per consultar-la.
• Tractar la família com un calaix rígid. Alguns patrons tenen un peu a dos mons i a la pràctica es combinen constantment (una fàbrica que retorna estratègies, un composite recorregut per un visitor). La classificació orienta; no tanca.
• Ignorar l'eix d'àmbit. Gairebé tothom coneix les tres famílies i gairebé ningú l'eix classe/objecte, que és just el que explica per què existeixen parelles de patrons "bessons" i quin triar. Tenir-lo present et donarà avantatge als mòduls 3 i 4.
• Creure que el mapa GoF és tot el territori. Si només coneixes els 23, intentaràs resoldre amb ells problemes que pertanyen a una altra escala (arquitectura, distribució, concurrència). Part del criteri és saber quan el teu problema ni tan sols és d'aquesta família; el mòdul 6 existeix per a això.
• Consell: imprimeix o desa les tres taules de la secció 3. Tornar-hi després d'estudiar cada patró ("continuo estant d'acord amb aquesta línia de resum?") és una tècnica de repàs excel·lent: quan totes les línies et semblin òbvies, dominaràs el catàleg.

Per a cada problema, indica quina família de patrons (creacional, estructural o de comportament) l'abordaria. No anomenis patrons concrets: raona només per la naturalesa del problema.

1. Quan una comanda passa a "lliurada", se n'han d'assabentar el client, el sistema de fidelització i les estadístiques.
2. El proveïdor extern de mapes té una API amb mètodes i tipus que no encaixen amb les interfícies de rutes de PideYa.
3. Muntar un objecte Comanda vàlid exigeix combinar cistella, adreça, franja horària, descomptes i propina, amb moltes combinacions opcionals.
4. La carta d'un restaurant conté seccions, que contenen plats o subseccions, i cal calcular preus i al·lèrgens sobre el conjunt.
5. Segons el país, PideYa ha de fer servir un joc complet i coherent de: passarel·la de pagament, calculadora d'impostos i formatador de tiquets.

Sense conèixer encara els patrons, raona: per què un patró d'àmbit d'objecte permet canviar el comportament en temps d'execució i un d'àmbit de classe no? Il·lustra-ho amb l'exemple del Repartidor i el seu Vehicle de la lliçó de principis.

Indica si cada problema pertany al territori del GoF o a una altra família de patrons (arquitectònica, concurrència, distribuïts/empresa):

1. Decidir si PideYa s'estructura com a monòlit en capes o com a microserveis.
2. Evitar que dos fils que processen pagaments simultanis corrompin el saldo del moneder.
3. Fer que la classe Comanda no conegui els detalls dels canals de notificació.
4. Reintentar i aïllar les crides al servei extern de pagaments quan aquest es degrada.

Solució 1:

1. De comportament: és un problema de comunicació/col·laboració entre objectes (notificar canvis sense acoblar-se).
2. Estructural: cal fer encaixar interfícies incompatibles component/embolcallant objectes existents.
3. Creacional: el problema és com construir un objecte complex amb moltes variants.
4. Estructural: és una composició d'objectes en arbre tractant uniformement parts i conjunts.
5. Creacional: cal crear famílies coherents d'objectes relacionats segons una condició (el país).

Solució 2: en un patró d'àmbit de classe, la relació s'estableix per herència: quin comportament té cada classe queda decidit en compilar, i un objecte no pot canviar de classe un cop creat. En un d'àmbit d'objecte, la relació és una referència a un altre objecte, i una referència es pot reassignar en qualsevol moment. Amb l'exemple: si modelem RepartidorEnMoto extends Repartidor, un repartidor "és" de moto per sempre (caldria destruir l'objecte i crear-ne un altre). Si Repartidor té un Vehicle, n'hi ha prou amb repartidor.assignarVehicle(new Bicicleta()) a mig torn: el comportament (temps de lliurament) canvia en calent sense canviar d'objecte.

Solució 3:

1. Arquitectònica: decideix la forma global del sistema, una escala per sobre del disseny de classes (mòdul 6).
2. Concurrència: coordinació de fils i estat compartit (mòdul 6).
3. GoF: disseny de col·laboració entre classes dins de l'aplicació (mòdul 4).
4. Distribuïts/microserveis: resiliència davant de serveis remots degradats (mòdul 6).

Ja tens el mapa complet: dos eixos de classificació (propòsit i àmbit), tres famílies amb la seva pregunta característica —creacionals: com neixen els objectes?; estructurals: com es componen?; de comportament: com col·laboren?—, la taula dels 23 patrons del GoF com a índex de consulta, i la ubicació de les famílies modernes (arquitectura, concurrència, empresa, distribuïts) que esperen al mòdul 6. També saps llegir el detall que gairebé tothom passa per alt: l'eix classe/objecte, que explica per què la composició domina el catàleg.

Abans de llançar-nos al primer patró queda una última parada, potser la que més maduresa professional aporta: sospesar honestament el que els patrons donen i el que costen, i aprendre a decidir quan usar-los i quan no. És la lliçó que tanca aquest mòdul: Avantatges i Desavantatges d'Usar Patrons de Disseny.