Prima che avessero un nome
Scrivi una classe che deve esistere una volta sola in tutto il programma. Poi un oggetto che deve avvisare altri tre ogni volta che cambia stato. Poi un pezzo di codice che deve funzionare con quattro algoritmi diversi senza sapere quale gli arriverà. E a un certo punto ti fermi, perché queste forme le hai già scritte. Non ricordi dove, ma la mano se le ricorda.
Per i primi decenni del software è stato questo lo stato normale. Le stesse strutture tornavano nei programmi di persone che non si erano mai parlate, ognuno le riscopriva da capo, e nessuno aveva una parola per dirle. Se volevi spiegare a un collega cosa stavi facendo, la disegnavi alla lavagna. Ogni volta da zero.
La parola è arrivata da fuori, da un posto che con i computer non c'entrava niente.
Nel 1977 un architetto, Christopher Alexander, pubblica A Pattern Language: duecentocinquantatré voci sulle forme ricorrenti delle case e delle città. Un cortile aperto su un lato, perché quelli chiusi su quattro lati restano vuoti. Una finestra su due pareti della stanza. Una strada abbastanza stretta da far incontrare due persone che si salutano. Alexander non ha mai scritto una riga di codice, e il libro non parla di software nemmeno per sbaglio.
Ha fatto presa per un motivo preciso: non erano progetti da copiare. Ogni voce descriveva un contesto, le forze che tiravano in direzioni opposte, e una forma che le teneva insieme senza risolverle del tutto. Chi scriveva programmi ci ha riconosciuto il proprio mestiere. Anche lì il lavoro non è trovare la risposta giusta, è tenere insieme vincoli che si contraddicono, e sapere cosa stai sacrificando.
Nel 1987 Kent Beck e Ward Cunningham fanno il passo: presentano a una conferenza un piccolo insieme di pattern per le interfacce in Smalltalk. Prendono la parola di un architetto e la portano dentro il codice. Sembra un dettaglio da storici. È il momento in cui un mestiere giovane si accorge di avere già delle abitudini, e decide di guardarle in faccia.
Il 1994
Sette anni dopo esce Design Patterns, firmato da quattro autori che tutti avrebbero poi chiamato Gang of Four. Ventitré pattern. Singleton, Observer, Factory, Strategy, Decorator, Visitor e gli altri.
Il libro non ha inventato niente. Quelle strutture erano già dentro i programmi che le persone scrivevano ogni giorno, spesso senza accorgersene. Quello che il libro ha inventato è un vocabolario.
Ed è qui che la storia diventa interessante, perché un pattern non è codice. Non lo puoi compilare, non lo puoi eseguire, non lo trovi da nessuna parte nel binario. Esiste solo nella testa delle persone che lo riconoscono. È una finzione condivisa, nel senso più letterale: qualcosa che è reale perché in tanti abbiamo deciso di crederci insieme. E funziona esattamente per questo. Due sviluppatori che non si sono mai visti possono dire "Observer" e intendere la stessa cosa.
Provate a misurare il risparmio. Una parola sola al posto di venti minuti di lavagna. Una parola che porta con sé non solo la forma, ma anche i suoi difetti noti, le sue alternative, il motivo per cui a volte non conviene. Il software è cresciuto oltre la dimensione di una singola testa nello stesso modo in cui sono cresciute le città: non trovando persone più intelligenti, ma inventando parole che permettono a estranei di coordinarsi.
Poi i pattern hanno addomesticato noi
Le storie di successo raramente restano innocenti a lungo.
Il vocabolario è diventato un programma di studio. Il programma di studio è diventato un rito di colloquio. Il rito di colloquio ha prodotto una generazione che sapeva elencare i ventitré nomi e riconoscerne forse tre nel codice vero. Nel frattempo, negli anni Duemila, l'industria enterprise ha preso il catalogo come una lista della spesa, e ha costruito cattedrali di astrazione dove sarebbero bastate tre funzioni. Nelle librerie di quel periodo esiste davvero una classe che si chiama AbstractSingletonProxyFactoryBean. Non è una battuta di qualcuno: è documentazione ufficiale.
La domanda che resta è la stessa che ci si può fare sull'agricoltura. Abbiamo addomesticato noi i pattern, o i pattern hanno addomesticato noi? Il grano prometteva più cibo e ha consegnato giornate più lunghe e schiene più curve. Il catalogo prometteva meno lavoro e ha consegnato, per un decennio buono, molte più righe di codice da mantenere.
Non credo che la colpa fosse del libro. Gli autori scrivevano di forze e di compromessi, e ripetevano che ogni pattern ha un costo. Ma un nome viaggia più veloce del ragionamento che lo giustifica, e arriva più lontano. Dopo qualche passaggio di mano resta solo il nome. È così che una parola smette di essere uno strumento e diventa una parola d'ordine.
Dove sono finiti
Se guardate un progetto moderno, i ventitré nomi sembrano scomparsi. Non è vero: sono stati assorbiti.
Iterator è diventato un ciclo for sul linguaggio. Strategy è una funzione passata come argomento. Command è una closure, oppure un messaggio in coda. Observer è un event stream, o un signal, o una primitiva che il framework ti dà gratis. Già nel 1996 Peter Norvig faceva notare che sedici dei ventitré pattern diventano invisibili o molto più semplici in un linguaggio dinamico. Non perché il problema sparisca, ma perché il linguaggio ha smesso di far pagare quella forma.
Da qui viene la lettura che trovo più utile di tutte: un design pattern è il sintomo di qualcosa che il linguaggio o la piattaforma non ti danno ancora. Quando lo danno, il pattern smette di essere un pattern e diventa una parola chiave, e nessuno ne parla più.
Il che spiega anche perché non si sono estinti, ma hanno cambiato piano. Quando i sistemi si sono spezzati in servizi che si parlano attraverso una rete inaffidabile, sono tornate le stesse forme ricorrenti a un livello più alto: circuit breaker, retry con backoff, chiave di idempotenza, outbox, saga, CQRS, sidecar. Nomi diversi, meccanismo identico. Qualcuno risolve lo stesso problema per la ventesima volta, si accorge che sta ridisegnando la stessa cosa, e le dà un nome perché il ventunesimo non debba ricominciare da capo.
Un nuovo 1994
Oggi siamo di nuovo all'inizio del ciclo, e questa volta lo stiamo vivendo in diretta.
Chi costruisce sistemi con i modelli linguistici ha ricominciato a riconoscere forme ricorrenti e a battezzarle da meno di due anni: prompt chaining, routing, orchestrator-workers, evaluator-optimizer, tool use, retrieval, guardrail. Sono descritte in articoli tecnici, non in un libro autorevole, e cambiano nome ogni sei mesi. Cioè: siamo esattamente al 1987, non al 1994. Il catalogo non è ancora stato scritto, e la parte divertente è che nessuno sa quali di questi nomi sopravvivranno.
C'è però una differenza che vale la pena guardare bene. I pattern classici esistevano anche per un motivo pratico: scrivere quel codice a mano costava tempo, e ricordarlo costava memoria. Oggi il codice che istanzia una forma nota costa poco. La parte cara è un'altra: capire quale forma serve, e cosa si paga scegliendola.
Se un pattern è un nome dato a un compromesso, allora quando scrivere il codice diventa gratis il valore non scende. Si sposta tutto sul nome.
Cosa resta
Non so come finisce, e diffido di chi lo racconta con troppa sicurezza. Vedo tre strade possibili, e probabilmente convivranno.
La prima è la ripetizione del passato: i pattern degli agenti verranno assorbiti dai framework e dai runtime, come è successo a Iterator, e tra cinque anni saranno una funzione che si chiama passandole tre parametri. È l'esito più probabile per la maggior parte di loro.
La seconda è che il vocabolario sopravviva anche quando il codice sotto è cambiato del tutto, perché serve a noi, non alle macchine. Le parole condivise sono l'unico modo che abbiamo per prendere decisioni in gruppo senza rileggere ogni volta l'intero sistema.
La terza è la più scomoda. I pattern sono nati per due limiti umani: dimentichiamo, e dobbiamo metterci d'accordo. Se una parte crescente del codice viene scritta e riletta da qualcosa che non dimentica e che non ha bisogno di mettersi d'accordo con nessuno, quella pressione si allenta. Il rischio non è che i nomi spariscano. È il contrario: che restino in circolazione molto dopo che la ragione per cui erano nati si è dissolta, ripetuti da chi progetta e da chi genera, con la stessa fedeltà e nessuna delle domande.
Contro questo ho una sola difesa, ed è piccola.
Prima di usare il nome di un pattern, prova a dire cosa risolve e cosa costa, in una frase, senza pronunciarlo. Se non ci riesci, non stai usando uno strumento: stai ripetendo una parola.
Vale per Singleton nel 2004 e per orchestrator-workers nel 2026. La domanda utile non è mai stata «quale pattern è questo». È «quali forze sto tenendo insieme, e cosa sto perdendo per farlo». Il nome viene dopo, e serve solo perché qualcun altro capisca in fretta.