Ja coneixes els cinc patrons creacionals per separat. Aquesta darrera lliçó del mòdul els posa sobre la mateixa taula, que és on es prenen les decisions reals: rarament la pregunta és "com funciona Builder?" sinó "què uso aquí: un builder, una fàbrica, o res?". Compararem intencions i costos, et donaré una guia de decisió en forma de diagrama, veurem com es combinen entre si (en el codi real gairebé mai no apareixen sols) i quina és la seva evolució típica en la vida d'un projecte. Tancarem amb el mapa creacional complet de PideYa: quin patró va quedar instal·lat a cada part del sistema i per què.

1. Els cinc, cara a cara
2. Guia de decisió
3. Com es combinen entre si
4. L'evolució típica: els patrons es guanyen
5. El mapa creacional de PideYa
6. Errors comuns, exercicis i conclusió

La taula que convé tenir interioritzada (les columnes de cost reprenen la balança de la lliçó 01-06):

Dos eixos transversals que ajuden a no confondre'ls:

• On és la dificultat? A triar la classe → fàbriques (una peça: Factory Method; família coherent: Abstract Factory). A muntar l'objecte → Builder. Al punt de partida (ja n'existeix un d'igual) → Prototype. A quantes instàncies → Singleton.
• Què se li dona al mecanisme? A una fàbrica se li donen paràmetres i decideix la classe; a un builder se li donen dades a poc a poc i munta; a un prototip no se li dona res: ja conté el seu estat.

El flux de preguntes que resumeix el mòdul. Com tota guia, orienta el 90% dels casos; el 10% restant és criteri (i recorda el filtre previ a tots: de debò fa mal el new directe?):

Tres consells d'ús de la guia:

• Les respostes poden ser diverses alhora: una comanda complexa (Builder) la passarel·la de cobrament de la qual tria una fàbrica de mercat (Abstract Factory) és el normal, no l'excepció. La guia s'aplica per decisió de creació, no per sistema.
• Quan dubtis entre Factory Method i Abstract Factory, la pregunta discriminant és sempre la mateixa: hi ha invariant de coherència entre diversos productes? Sense família, no hi ha Abstract Factory.
• Quan dubtis entre Builder i fàbrica: la fàbrica amaga quina classe; el builder amaga quins passos. Si el client coneix perfectament la classe (Comanda) però pateix muntant-la, és Builder.

Els creacionals són peces de Lego, i en el codi real apareixen assemblats. Les combinacions canòniques, totes presents o plausibles a PideYa:

• Abstract Factory implementada amb Factory Methods. Cada mètode crearX() de FabricaEspanya és un factory method: la fàbrica abstracta és, estructuralment, un paquet de factory methods agrupats per variant. Ho vas veure a la lliçó 02-04.
• Fàbriques exposades com a Singleton (o millor, injectades com a instància única). FabricaMexic no té estat propi: no hi ha motiu per instanciar-la més d'una vegada. L'habitual: instància única creada a l'arrel de composició i injectada; el Singleton clàssic queda per al cas sense contenidor.
• Builder dins d'una fàbrica. Una fàbrica el producte de la qual és complex el munta internament amb el seu builder: FabricaEspanya.crearFormatadorTiquet() pot retornar FormatadorTiquet.builder().normativa(ES).moneda(EUR).build(). El client veu fàbrica; la fàbrica usa builder. Cada patró resol la seva capa.
• Fàbrica que retorna el builder. Comanda.builder(client, restaurant) —el nostre punt d'entrada de la lliçó 02-05— és un mètode estàtic de fabricació... que fabrica un builder. La combinació és tan natural que ni es nota.
• Abstract Factory implementada amb Prototype. En comptes d'una classe de fàbrica per mercat, un joc d'exemplars prototípics per mercat que la fàbrica clona. Útil quan les variants es defineixen per configuració (dades) més que per codi.
• Registre (de Suppliers o de prototips) com a columna vertebral. El registre de la lliçó 02-03 i el de plantilles de la lliçó 02-06 són el mateix esquelet amb farciment diferent: receptes en un, exemplars en l'altre. Tots dos converteixen "afegir una variant" en "registrar una entrada", sense tocar el nucli.

La seqüència que has vist a les lliçons no és casual: és la trajectòria natural d'un punt de creació durant la vida d'un projecte sa. Convé tenir-la explícita, perquè et diu quan aturar-te:

Cada fletxa té un peatge d'entrada: el símptoma que la justifica. Recórrer-la sencera "per si de cas" el primer dia és la sobreenginyeria de la lliçó 01-06; quedar-se en new directe quan ja hi ha tres switch duplicats és l'error simètric. PideYa va recórrer la seqüència completa només en pagaments i impostos (on la internacionalització l'exigia); les notificacions es van quedar al registre de Suppliers; i desenes d'objectes petits continuen feliçment en new directe. Les tres parades són correctes: cadascuna és la resposta proporcionada al seu nivell de dolor. Builder i Prototype orbiten a part d'aquesta seqüència: no evolucionen des de la fàbrica sinó des de l'objecte (constructor que s'engreixa → Builder; reconstrucció repetitiva → Prototype). I el camí invers també existeix: si les variants d'una Abstract Factory es redueixen a una i res no apunta que tornin, degradar-la a fàbrica simple és refactoritzar bé, no rendir-se (més sobre això a Refactorització Usant Patrons).

Tanquem el mòdul com va començar: mirant el sistema sencer. Això és el que va quedar instal·lat, lliçó a lliçó, amb la seva justificació en una línia:

Fixa't en la darrera fila: és tan important com les altres. Un disseny madur no és el que més patrons té, sinó el que té cada patró on el seu símptoma el va justificar — la vara de mesurar que vam fixar a la lliçó de la balança.

• Triar per familiaritat, no per problema. "Uso Factory Method perquè és el que conec millor" produeix fàbriques on calia un builder. La guia de decisió existeix per forçar les preguntes correctes abans que les respostes còmodes.
• Confondre la parella estrella. Factory Method i Abstract Factory continuaran confonent-se en entrevistes i revisions; recita el discriminant: un mètode que crea un producte davant un objecte que crea una família coherent.
• Saltar-se esglaons de l'evolució. Muntar l'Abstract Factory de mercats quan PideYa només operava a Espanya hauria estat flexibilitat especulativa pura. El peatge de cada fletxa es paga quan el símptoma arriba, no abans.
• No desmuntar patrons que ja no paguen. L'evolució també va cap enrere: mantenir una jerarquia de fàbriques per a una única variant des de fa dos anys és deute estructural amb disfressa de disseny.
• Tractar les combinacions com a excepcions. Un builder dins d'una fàbrica, o una fàbrica que retorna builders, no és "barrejar patrons": és el normal. Cada patró governa una capa de la decisió de creació.
• Consell: en el teu proper projecte, fes l'exercici del mapa: una taula com la de PideYa amb cada punt de creació rellevant, la seva solució i la seva justificació en una línia. Si alguna fila no es pot justificar amb un símptoma, tens un candidat a simplificar.

Per a cada situació nova a PideYa, tria el patró creacional (o l'absència de patró) i justifica-ho en una frase amb el discriminant adequat:

1. El mòdul d'informes ha de generar un objecte PanellEstadistiques amb 12 widgets configurables, llindars opcionals i validació de rangs.
2. Màrqueting vol campanyes d'email el contingut de les quals es defineix visualment en un panell d'administració; cada campanya nova parteix d'una d'existent "que va funcionar".
3. En integrar recollida a botiga per a supermercats, cada cadena (Mercadona, Carrefour) exigeix la seva API d'estoc, el seu format de codi de barres i la seva passarel·la de fidelització, sempre a joc.
4. Un desenvolupador proposa fer singleton la CistellaActual "per accedir-hi des de qualsevol pantalla de l'app".
5. Cal crear l'objecte ExportadorDades adequat (CSV, JSON o Parquet) segons un paràmetre; avui hi ha tres formats i no es preveuen famílies ni coherències.

Descriu quins patrons creacionals col·laboren en aquest fragment i quin paper compleix cadascun:

El generador de codis promocionals de PideYa va néixer com a new GeneradorCodis() en un únic servei. Avui: (a) màrqueting demana codis alfanumèrics per a campanyes normals i codis QR per a campanyes de cartelleria; (b) el switch que els distingeix ja està copiat en dos serveis. Descriu l'evolució pas a pas que aplica la seqüència de la secció 4, indicant a quina parada t'aturaries avui i quin símptoma futur et faria avançar a la següent.

Solució 1:

1. Builder: la classe és coneguda i el problema és el muntatge (opcionals + validació creuada).
2. Prototype amb registre: els exemplars es defineixen amb dades en execució i el punt de partida natural és una campanya existent; cap solució basada en classes noves no encaixa amb un panell d'administració.
3. Abstract Factory: tres peces per cadena amb invariant de coherència ("sempre a joc"): família de manual.
4. Cap patró, i a més rebuig raonat: la cistella és estat de negoci mutable i per usuari; un singleton la compartiria entre sessions (bug greu) i amagaria la dependència. Correspon a la sessió/context, injectada.
5. Simple factory (o registre de Supplier si es preveuen més formats): un producte, sense famílies; amb tres casos estables, l'idiom basta i el patró complet seria cerimònia.

Solució 2: hi col·laboren Abstract Factory (la classe FabricaMexic, que garanteix la família coherent del mercat mexicà), Factory Method (el mètode crearFormatadorTiquet() és un dels seus factory methods: decideix el producte concret d'aquesta variant) i Builder (FormatadorTiquet.builder()...build() munta el producte complex pas a pas, amb la validació que correspongui a build()). Tres capes de la mateixa decisió: quina família → quin producte → com es munta.

Solució 3: evolució raonable: (1) el new directe va deixar de bastar quan va aparèixer la segona classe concreta (alfanumèric/QR) i el switch es va duplicar: símptomes clars → extreure una simple factory (FabricaGeneradorsCodi.crear(tipus)) que deduplica i centralitza. (2) Parada actual: aquí m'aturaria avui — dues variants estables i un sol punt de decisió no justifiquen més. (3) Símptoma que faria avançar a Factory Method/registre de Suppliers: noves variants amb cadència real (codis per partner, per app externa) o la necessitat que altres mòduls registrin generadors sense tocar el nucli. (4) Abstract Factory només entraria si algun dia cada campanya exigís diverses peces coherents (generador + validador + render, a joc per tipus de campanya); avui aquesta família no existeix, així que anticipar-la seria especulació.

El mòdul va començar amb una pregunta —qui decideix quina classe concreta s'instancia, i on?— i ara tens cinc respostes amb els seus discriminants: Singleton per a la unicitat (millor, injecció), Factory Method per variar el producte, Abstract Factory per blindar famílies, Builder per domar el muntatge, Prototype per partir d'un exemplar. Saps que es combinen per capes, que s'hi arriba per una evolució guiada per símptomes —i que s'abandonen igual—, i tens el mapa de PideYa com a plantilla del resultat final: cada patró on el seu dolor el va justificar, i new directe on no hi havia dolor.

Amb el naixement dels objectes resolt, la següent pregunta és inevitable: un cop creades les peces —passarel·les, notificadors, comandes—, com es connecten i organitzen entre si sense que el conjunt es torni un embolic? Aquesta és la segona família del catàleg: adaptar interfícies que no encaixen, compondre estructures en arbre, embolcallar objectes amb responsabilitats extra, simplificar subsistemes sencers rere una façana. Ens veiem a la Introducció als Patrons Estructurals.