Els patrons de disseny no van néixer a la informàtica. Van néixer a l'arquitectura —la d'edificis i ciutats— de la mà de Christopher Alexander, i van ser adoptats per la comunitat del programari als anys 90 fins a cristal·litzar en un dels llibres més influents de la història de la programació: Design Patterns, de l'anomenat Gang of Four. Conèixer aquesta història no és mera cultura general: entendre per què van sorgir els patrons, quin problema intentaven resoldre els seus autors i com han evolucionat des de 1994 t'ajudarà a usar-los amb criteri, a saber quines parts del catàleg original han envellit i a reconèixer patrons allà on avui viuen: dins dels llenguatges i frameworks que fas servir cada dia.

1. Christopher Alexander: patrons a l'arquitectura
2. El salt al programari: d'OOPSLA al Gang of Four
3. Design Patterns (1994): el llibre que ho va canviar tot
4. L'evolució posterior: POSA, Fowler i els patrons d'empresa
5. Patrons als frameworks i llenguatges moderns
6. Per què continuen vigents 30 anys després?

Als anys 70, l'arquitecte austríac-britànic Christopher Alexander (1936–2022), professor a Berkeley, es va fer una pregunta aparentment simple: per què alguns llocs construïts per l'ésser humà —una plaça de poble, un pati, un cafè amb finestrals— ens resulten vius i agradables, mentre que d'altres, tècnicament correctes, resulten freds i inhòspits?

La seva resposta va ser que els bons espais repeteixen certes configuracions que resolen tensions recurrents entre les persones i el seu entorn. Cadascuna d'aquestes configuracions la va anomenar patró, i les va documentar en dues obres fonamentals:

• A Pattern Language (1977): un catàleg de 253 patrons d'arquitectura i urbanisme, des de l'escala d'una regió fins a la d'un racó d'una habitació. Cada patró té nom (per exemple, "Llum a dos costats de cada habitació"), descriu el context, les forces en conflicte i la solució.
• The Timeless Way of Building (1979): la teoria que sustenta el catàleg, on apareix la seva definició més citada:

«Cada patró descriu un problema que ocorre una vegada i una altra al nostre entorn, i descriu el nucli de la solució a aquest problema, de tal manera que puguis usar aquesta solució un milió de vegades sense fer-ho mai dues vegades de la mateixa manera.»

Fixa't que aquesta frase de 1977, escrita sobre edificis, descriu amb precisió el que vam veure a la lliçó anterior sobre patrons de programari: solució reutilitzable però mai idèntica, sempre adaptada al context.

Dues idees d'Alexander van resultar especialment fèrtils per al programari:

• Els patrons es connecten formant un llenguatge. No són fitxes soltes: un patró de gran escala (una plaça) crea el context on apliquen patrons menors (porxos, bancs al sol). En programari passa igual: els patrons es combinen i es criden els uns als altres.
• El format problema–forces–solució. La disciplina de documentar per què funciona una solució, i no només com és, és la gran herència metodològica d'Alexander.

A finals dels 80, diversos investigadors de la programació orientada a objectes van llegir Alexander i hi van veure el paral·lelisme. Les fites principals:

Els quatre autors del llibre són coneguts universalment com el Gang of Four («la banda dels quatre»), abreujat GoF. Quan sentis «els patrons del GoF» o «el llibre del GoF», es refereix a ells i al seu catàleg.

Un detall important: el GoF no va inventar els patrons que va documentar. Els va descobrir i destil·lar observant sistemes reals ben dissenyats (frameworks gràfics com ET++ i InterViews, Smalltalk, editors de documents...). Aquesta és l'essència del treball amb patrons: es cullen de l'experiència, no s'inventen en una pissarra.

El llibre del GoF documenta 23 patrons de disseny orientat a objectes, cadascun amb la fitxa estandarditzada que vam veure a la lliçó anterior (intenció, motivació, aplicabilitat, estructura, participants, conseqüències, implementació...). Els exemples originals són en C++ i Smalltalk, els llenguatges orientats a objectes dominants de l'època.

Per què va ser tan influent? Per tres aportacions que continuen vigents:

1. Va crear un vocabulari compartit. Abans de 1994, cada equip reinventava i rebatejava les mateixes estructures. Després, "Observer", "Factory Method" o "Decorator" es van convertir en paraules de l'idioma comú de la professió, presents en entrevistes de feina, documentació i noms de classes de les llibreries estàndard.
2. Va elevar el nivell del discurs sobre disseny. Va permetre parlar d'arquitectures de classes completes ("aquí hi ha un Composite recorregut per un Visitor") en lloc de descriure classe a classe.
3. Va destil·lar principis en solucions aplicables. El llibre obre amb dues màximes que estudiarem a fons a la lliçó Principis de Disseny: «programa contra una interfície, no contra una implementació» i «afavoreix la composició d'objectes per sobre de l'herència de classes». Els 23 patrons són, en gran mesura, aplicacions concretes d'aquestes dues idees.

El llibre va organitzar els seus 23 patrons en tres famílies (creacionals, estructurals i de comportament) que continuen sent la classificació de referència; la veurem en detall a la lliçó Classificació dels Patrons de Disseny, i és també l'estructura dels mòduls 2, 3 i 4 d'aquest curs.

L'impacte va ser enorme: és un dels llibres tècnics més venuts i citats de la història del programari, i el 2005 els seus autors van rebre per ell el premi Programming Languages Achievement Award d'ACM SIGPLAN.

L'èxit del GoF va obrir una etapa molt productiva: la comunitat es va dedicar a collir patrons en altres nivells i dominis. Les fites que més et convé conèixer:

La sèrie Pattern-Oriented Software Architecture (POSA, 5 volums, iniciada per Frank Buschmann i altres el 1996) va pujar l'escala: del disseny de classes a l'arquitectura de sistemes complets. De POSA en surten noms que avui són omnipresents:

• Layers (arquitectura en capes): la separació presentació / negoci / persistència que fa servir gairebé qualsevol aplicació, inclosa PideYa.
• Model-View-Controller (MVC): documentat com a patró arquitectònic (la idea original venia de Smalltalk, anys abans).
• Broker, Pipes and Filters, Microkernel... i en volums posteriors, patrons de concurrència com Reactor o Half-Sync/Half-Async.

Martin Fowler va publicar el 2002 Patterns of Enterprise Application Architecture (PoEAA), centrat en els problemes típics de les aplicacions de negoci: accés a dades, transaccions, presentació web. Si has fet servir un ORM com Hibernate/JPA, has usat els seus patrons sense saber-ho:

• Repository i Data Mapper: separar el domini de la base de dades (així funcionen els repositoris de Spring Data que podria fer servir PideYa per desar comandes).
• Unit of Work: agrupar canvis i confirmar-los junts (el cor d'una sessió de JPA).
• Domain Model, Service Layer, Lazy Load, Active Record...

En paral·lel van aparèixer catàlegs per a altres dominis: Enterprise Integration Patterns (Hohpe i Woolf, 2003) per a missatgeria entre sistemes, patrons de programació concurrent, i més recentment catàlegs de patrons per a microserveis i sistemes distribuïts (Circuit Breaker, Saga, API Gateway...). No els desenvoluparem ara: el mòdul 6 d'aquest curs està dedicat precisament a aquests patrons moderns.

Des dels 2000, els patrons han seguit dos camins complementaris:

Avui rarament implementes certs patrons a mà, perquè el framework ja els porta fets. Alguns exemples que reconeixeràs quan estudiem cada patró:

Un fenomen interessant: el que en un llenguatge exigeix un patró, en un altre és una característica nativa. Es diu que alguns patrons són «símptomes» del que li falta a un llenguatge:

• Les lambdes i referències a mètodes de Java 8+ fan trivial el que abans requeria classes senceres de Strategy o Command.
• Els enum de Java ofereixen la forma més robusta d'escriure un Singleton (ho veuràs al mòdul 2).
• Llenguatges amb funcions de primera classe (JavaScript, Python, Kotlin) gairebé no necessiten certs patrons de comportament en la seva forma clàssica.

Això no vol dir que els patrons "hagin mort": vol dir que el problema continua existint i que convé conèixer-lo, encara que la solució de vegades sigui una línia de llenguatge modern en lloc de tres classes. Saber que aquella lambda és una Strategy et permet parlar-ne, documentar-la i fer-la evolucionar amb criteri.

Val la pena preguntar-se si un catàleg de 1994, amb exemples en C++, continua mereixent un curs a dia d'avui. La resposta és sí, per aquestes raons:

1. Els problemes no han canviat. Continuem necessitant crear objectes sense acoblar-nos a les seves classes, notificar canvis sense conèixer els interessats o afegir comportament sense tocar codi que funciona. Les forces de disseny són les mateixes a PideYa que en un editor de documents de 1993.
2. El vocabulari ja és infraestructura de la professió. Els noms del GoF apareixen a la documentació de Java, Spring o Android, a les revisions de codi i a les entrevistes tècniques. No conèixer-los et deixa fora de la conversa.
3. Són la porta d'entrada al disseny. Estudiar patrons és la manera més eficaç d'interioritzar els principis de disseny (els veurem a la propera lliçó): cada patró és un principi fet carn.
4. Han demostrat saber evolucionar. El moviment de patrons no es va congelar el 1994: va produir POSA, PoEAA, els patrons d'integració i avui els de microserveis. La pràctica de documentar problema-forces-solució continua viva i generant catàlegs nous.
5. Amb matisos. La vigència no és uniforme: alguns dels 23 es fan servir cada dia i d'altres han quedat relegats o es consideren avui problemàtics en la seva forma clàssica. Assenyalarem aquests matisos patró a patró, i el mòdul 5 dedica una lliçó sencera als antipatrons.

• Pensar que el GoF va inventar els patrons. Els va documentar: els patrons es cullen de sistemes reals que funcionen. Per això una solució del teu equip, per bona que sigui, només es converteix en patró quan s'ha repetit i validat en múltiples contextos.
• Tractar el llibre de 1994 com a dogma intocable. El catàleg reflecteix l'estat de l'art de C++/Smalltalk dels 90. Els problemes continuen vigents; algunes solucions concretes s'expressen avui d'una altra manera (lambdes, enums, frameworks). Estudia el problema, no només la solució literal.
• Ignorar tot el que és posterior al GoF. Si només coneixes els 23 clàssics, et faltarà el vocabulari d'arquitectura (POSA), d'empresa (Fowler) i de sistemes distribuïts que domina el desenvolupament actual. Aquest curs et dona el mapa complet: GoF als mòduls 2–4 i el que és modern al mòdul 6.
• Confondre la cronologia. Una relliscada típica en entrevistes: Alexander (arquitectura, 1977) → Beck/Cunningham (OOPSLA, 1987) → GoF (1994) → POSA (1996) → Fowler (2002). Tenir clara la seqüència ajuda a situar cada catàleg al seu nivell d'abstracció.
• Consell: fulleja (encara que sigui per curiositat) l'índex d'A Pattern Language. Veure patrons com "Finestra al sud" o "Plaça petita" descrits amb el mateix format que Observer és la millor manera d'interioritzar que un patró és problema+forces+solució, no codi.

Pren la cita d'Alexander («usar aquesta solució un milió de vegades sense fer-ho mai dues vegades de la mateixa manera») i explica, amb l'exemple de les notificacions de PideYa de la lliçó anterior, què significaria a la pràctica: què seria «la solució» reutilitzable i què canviaria en cada aplicació concreta?

Relaciona cada problema de PideYa amb el catàleg històric on buscaries la solució (GoF 1994, POSA, PoEAA de Fowler, o catàlegs de microserveis):

1. Decidir com separar l'aplicació en capes de presentació, negoci i persistència.
2. Afegir canals de notificació (email, SMS, push) sense modificar la classe Comanda.
3. Desar i recuperar comandes de la base de dades sense que el domini conegui SQL.
4. Evitar que la caiguda del servei de pagaments tombi en cascada tota la plataforma.

Sense haver estudiat encara cap patró, localitza al JDK de Java dos noms de classe o interfície que continguin literalment el nom d'un patró del GoF (pista: busca entre java.util i java.io). Indica què suggereix això sobre la relació entre el catàleg de 1994 i les plataformes actuals.

Solució 1: «La solució» reutilitzable és l'estructura conceptual: que la comanda no conegui els seus interessats, sinó que existeixi un mecanisme de subscripció pel qual els interessats s'apunten i reben avisos. El que canvia en cada aplicació: els noms de les classes (a PideYa serien del domini de comandes), quins esdeveniments es notifiquen (canvis d'estat), qui s'hi subscriu (push, SMS, estadístiques), el llenguatge, i fins i tot detalls com si la notificació és síncrona o asíncrona. Dos equips que apliquin la mateixa solució produiran codis diferents: un milió d'usos, cap d'idèntic.

Solució 2:

1. POSA — la separació en capes és el patró arquitectònic Layers, documentat a POSA 1.
2. GoF 1994 — és un problema de disseny de classes (notificació desacoblada), territori del catàleg clàssic (ho veurem al mòdul 4).
3. PoEAA (Fowler) — separar domini i persistència és el terreny de Repository / Data Mapper / Unit of Work.
4. Catàlegs de microserveis / sistemes distribuïts — resiliència davant fallades de serveis remots (tipus Circuit Breaker); ho tractarà el mòdul 6.

Solució 3: els dos casos més clars són java.util.Iterator (patró Iterator) i java.util.Observer/java.util.Observable (patró Observer; desaprovats des de Java 9, cosa que és en si mateixa il·lustrativa: la plataforma manté el patró però en va millorar la implementació). També valen java.sql.DriverManager.getConnection(...) com a fàbrica o els *Builder com StringBuilder (amb matisos, ja que no és el Builder del GoF complet). El que suggereix: els autors de les plataformes modernes van adoptar el vocabulari del GoF fins al punt d'usar-lo a les APIs públiques; conèixer els patrons és conèixer l'idioma en què estan escrites les llibreries estàndard.

Ja coneixes el llinatge complet dels patrons de disseny: la intuïció de Christopher Alexander sobre els espais que funcionen, el salt al programari de Beck i Cunningham el 1987, la cristal·lització en els 23 patrons del Gang of Four el 1994, i l'expansió posterior cap a l'arquitectura (POSA), les aplicacions d'empresa (Fowler) i els sistemes distribuïts actuals. I, sobretot, saps per què continuen vigents: els problemes de disseny no caduquen, encara que les solucions es modernitzin.

En la història del GoF ha aparegut una idea clau: els seus 23 patrons són aplicacions concretes d'uns pocs principis de disseny ("programa contra interfícies", "afavoreix la composició..."). Abans d'estudiar cap patró necessitem dominar aquests principis, perquè són el criteri amb què jutjar qualsevol disseny. És l'objectiu de la propera lliçó: Principis de Disseny: SOLID i Altres Fonaments.