Ovvero: come passare da if annidati a design pattern eleganti (con una punta di sarcasmo).

I design pattern sono come le ricette segrete della nonna: tutti ne parlano, in tanti li usano, pochi li capiscono davvero fino in fondo. Tra i pattern più chiacchierati nei corridoi (fisici o virtuali) dei team di sviluppo c’è il Pattern Strategy, spesso osannato come la soluzione elegante a quel mostro spaghetti-code fatto di if e switch interminabili. Ma non è solo: ha una comitiva di cugini altrettanto affascinanti (e subdoli) come State, Template Method e Command, con cui condivide categoria (sono pattern comportamentali) e una certa predisposizione a complicare la vita a chi li implementa senza cognizione di causa.

In questo articolo, esploreremo lo Strategy e compagnia bella. Lo faremo con spiegazioni semplici e ironiche, evidenziando pro, contro, difficoltà d’implementazione, e quando usarli (oltre a quando no, con qualche esempio tragicomico). Preparatevi: patternite acuta e sarcasmo q.b. per far sentire ogni dev a casa!

Strategy: il cambio d’algoritmo con stile (e qualche classe in più)

Lo stratega del codice, quello che cambia tattica al volo per evitare il temuto “if infinito”.

Che cos’è (in parole povere): Il Pattern Strategy è un trucco da illusionista dell’OOP: invece di codificare un algoritmo direttamente, lo incapsuli in una classe dedicata e poi, quando serve, lo tiri fuori dal cilindro. In termini seri, “definisce una famiglia di algoritmi, li incapsula e li rende interscambiabili tra di loro, permettendo di variare l’algoritmo indipendentemente dai client che lo usano“.

In altre parole, puoi cambiare strategia di calcolo come cambi la cravatta a seconda dell’occasione, senza toccare il codice principale. Ti suona sofisticato? Lo è. Ti suona come un modo elegante di evitare 27 blocchi if-else? Lo è anche quello.

Immagina di dover ordinare dei dati: a volte vuoi farlo in modo ascendente, a volte discendente, a volte random (perché no?). Senza Strategy probabilmente avresti una bella serie di condizioni per decidere quale algoritmo usare. Con Strategy, invece, crei ad esempio una classe OrdinamentoAscendente, una OrdinamentoDiscendente e magari una OrdinamentoRandomico che implementano tutte un’interfaccia comune (tipo SortStrategy). Il codice principale (Context) le può scambiare a runtime come figurine, delegando a loro il lavoro sporco. Un po’ come dire: “Non so come ordinare questi dati, ma so a chi chiedere di farlo”. Elegante, no?

“Ho eliminato ogni if dal codice! Ora ho 15 classi nuove… ma niente if!”.
– Il Dev entusiasta dopo aver scoperto Strategy

Pro:

• Pulizia e Organizzazione: Riduce quei mega-metodi pieni di condizioni. Ogni algoritmo va nella sua classe dedicata – Marie Kondo approverebbe.
• Intercambiabilità: Puoi aggiungere nuove strategie senza toccare il codice esistente (Open/Closed Principle dicono quelli bravi). Domani vuoi un nuovo metodo di ordinamento? Crea una nuova classe Strategy e via.
• Testabilità: Ogni algoritmo è separato, quindi puoi testarli indipendentemente. Niente più esecuzioni contorte per coprire tutti i rami di quell’unico metodo mostruoso.

Contro:

• Overhead di codice: Diciamolo, per usare Strategy devi creare tante classi e oggetti. Se avevi due soli casi, forse quel if non era poi così demoniaco…
• Leggibilità non immediata: Apri il codice e trovi 5 classi in più col suffisso Strategy. Per chi non conosce il pattern, inizialmente è come perdersi in una festa in maschera: “Dov’è finita la logica?!”.
• Configurazione necessaria: Devi pur decidere da qualche parte quale strategia usare. Quindi un pizzico di logica condizionale finisce da qualche altra parte (fabbriche, configurazioni, o inizializzazioni ad hoc). Hai eliminato if dal codice business, ma magari ne hai aggiunto uno per scegliere la strategy giusta.

Difficoltà e sorprese nell’implementazione: Implementare Strategy sembra facile: definisci l’interfaccia, implementi N classi e fatto. Ma…

• Parametri eccessivi: Se le diverse strategie hanno bisogno di dati molto diversi, il metodo comune dell’interfaccia potrebbe diventare qualcosa come esegui(context, opzioni, flag1, flag2, …). Insomma, stai passando l’intera cucina al cuoco perché ogni piatto richiede ingredienti diversi – un campanello d’allarme che forse il pattern non è stato pensato bene in quel caso.
• Gestione delle istanze: Creare e distruggere oggetti strategia può avere un costo (specie se sono pesanti). A volte conviene tenerne una singleton, o passarle da fuori già pronte. In ogni caso, attenzione a non creare strategie usa e getta in un loop stretto, altrimenti la strategia più efficace sarà solo saturare la memoria!
• Debug più astratto: Se qualcosa va storto, il debugger ti porterà a spasso tra classi diverse. Doversi ricordare quale strategia è in uso in quel momento potrebbe farti venire il mal di testa (“Ma sta usando QuestaStrategia o QuellAltraStrategia adesso?”). Insomma, debugging un filino più complicato rispetto a un semplice flusso lineare.

Quando usarlo: Quando hai vari algoritmi intercambiabili e prevedi cambiamenti o estensioni frequenti. Ad esempio, calcolare prezzi con regole diverse, scegliere politiche di caching, decidere il comportamento di un AI nemica in un gioco (facile, normale, difficile: ogni livello è una strategia differente). In questi casi, Strategy ti fa aggiungere nuove varianti senza toccare il codice esistente, e ti evita di scrivere codice pieno di branching. È come assumere specialisti diversi per lo stesso compito: oggi chiedo al MetodoA, domani al MetodoB.

Quando evitarlo: Se hai una logica semplice, che difficilmente cambierà o per cui prevedi al massimo due varianti… beh, forse introdurre 3 interfacce e 5 classi è eccessivo. Un esempio comico? Usare il Strategy per decidere se stampare “Hello World” in maiuscolo o minuscolo: crea la StampaMaiuscoloStrategy e la StampaMinuscoloStrategy… e intanto il collega ha già scritto due console.log e sta prendendo un caffè. In generale, se ti ritrovi a implementare un pattern Strategy per risolvere qualcosa che poteva essere un semplice parametro ad una funzione, fermati un attimo: potresti essere in preda a patternite.

State: l’oggetto con personalità multiple (ma gestite bene)

Ovvero: invece di mille if sullo stato, diamo all’oggetto dissociativo delle classi dedicate per ciascuno dei suoi “umori”.

Che cos’è: Il Pattern State è il cugino strettissimo di Strategy – a volte li confondono pure all’asilo dei dev. Anche qui abbiamo un Context che delega ad altri oggetti, ma stavolta non li chiamiamo “strategie” bensì “stati”. L’idea è che un oggetto cambi comportamento al variare del suo stato interno, proprio come un camaleonte che cambia colore. Invece di una serie infinita di switch su un campo stato (con combinazioni tipo if (stato == X && evento == Y) ... che ti fanno venire il mal di mare), ogni stato possibile diventa una classe separata con la sua implementazione dei metodi. Il Context, a seconda di quale stato istanza è collegata, si comporterà diversamente chiamando i metodi di quello stato.

Un esempio classico: un player musicale con stati Stop, Play, Pause, Lock. Senza State pattern, avresti metodi tipo play() pieni di condizioni: se stato è Stop, fai questo; se è Pause, fai quest’altro; se è Play, fai niente; se è Lock, segnala errore… e così via per pause(), stop(), ecc. Con State pattern, invece, hai classi come StatoStop, StatoPlay, StatoPause, StatoLock che implementano ciascuna i metodi play(), pause(), etc. in modo appropriato per quello stato. Il Context (il player) contiene un riferimento allo State corrente e delega le chiamate: statoCorrente.play(), statoCorrente.pause(), ecc. Quando deve cambiare stato, sostituisce l’oggetto statoCorrente con un’altra istanza (e magari lo fa dall’interno di questi oggetti State stessi). Il risultato? Codice più pulito e organico: ogni stato “sa” come comportarsi, e il player principale non deve conoscere i dettagli di tutti gli stati.

Pro:

• Niente più spaghetti di stati: Elimina quelle macchine a stati codificate a mano piene di variabili booleane e condizioni annidate. Ogni stato ha il suo orticello (classe) con dentro solo la logica pertinente.
• Aggiungere stati è più facile: Vuoi introdurre uno stato Demo (es. modalità demo del player)? Crea una nuova classe che implementa l’interfaccia di stato e il gioco è fatto, senza toccare i if di uno switchone.
• Manutenzione locale: Ogni cambiamento nella logica di uno stato tocca solo la classe di quello stato. Minor rischio di rompere accidentalmente il comportamento per gli altri stati mentre sistemi quello arrabbiato.

Contro:

• Esplosione di classi: Se gli stati sono molti, preparati a un proliferare di classi come conigli dopo Pasqua. 5 stati = 5 classi (più l’interfaccia), 10 stati = 10 classi… potresti finire con più file .java/.cs/.py che stati d’animo in un adolescente.
• Transizioni complesse: La logica che cambia lo stato (il passaggio da uno all’altro) deve comunque stare da qualche parte. Spesso è distribuita tra il Context e gli stessi oggetti State (ogni stato decide quando e come passare ad un altro). Questo può diventare intricato se gli stati possibili sono tanti e le regole di transizione complicate. Insomma, rischi una giungla dove prima c’era un pantano.
• Overkill per stati semplici: Se il tuo oggetto ha solo due stati e poca logica, implementare il pattern potrebbe essere eccessivo (il classico kill a fly with a bazooka). Due if forse avrebbero fatto un lavoro egregio con molto meno sforzo.

Difficoltà e sorprese nell’implementazione:

• Condivisione di contesto: Gli oggetti stato spesso hanno bisogno di riferimenti al contesto (per poter cambiare lo stato corrente o interrogare altri dati). Ciò significa passare this o un riferimento del Context a ogni stato. È normale, ma va progettato con attenzione: occhio a non creare dipendenze cicliche infernali (lo Stato conosce il Context, il Context conosce lo Stato… sembra Beautiful ma è il tuo codice).
• Stati che cambiano sé stessi: Un pattern comune è che dentro, ad esempio, StatoPlay.pause() il codice faccia player.setStato(new StatoPause()). Cioè lo stato corrente decide di cambiare lo stato del contesto. Potente, ma attento: se sbagli a implementare questa transizione, potresti entrare in stati non validi o cicli di stati. Debuggare “perché passando da Play a Pause finisco in Lock” potrebbe farti strappar via ciocche di capelli.
• Duplicazione di codice: A volte diversi stati devono fare cose simili. Puoi mettere logica comune nel Context o in una superclasse degli stati, ma occhio a non finire con un miscuglio di logica in posti diversi. Ops, dove l’ho messa quella check? Nel Context o nello stato? Se ti fai questa domanda troppo spesso, qualcosa non va.

Quando usarlo: Quando un oggetto può trovarsi in molti stati diversi e la logica da eseguire dipende fortemente dallo stato in cui si trova. Classico: macchine a stati finiti, workflow con passi multipli, oggetti che cambiano comportamento nel tempo. Ad esempio, un ordine che può essere Nuovo, In elaborazione, Spedito, Consegnato, Annullato, ciascuno con azioni diverse consentite. Se implementato con State, aggiungere lo stato Reso a posteriori sarà indolore (nuova classe e via). Senza, saresti andato a caccia di tutti gli if (stato == XYZ) sparsi per il codice.

Quando evitarlo: Se gli stati sono pochi e gestibili, o se la logica per cambiare comportamento è minima, il gioco potrebbe non valere la candela. Un esempio ironico? Immagina un interruttore On/Off implementato col pattern State: StatoOn e StatoOff con due classi separate, ognuna con un metodo premiInterruttore() che istanzia l’altra. Funziona, certo… ma forse un banale if (acceso) acceso=false else acceso=true era più che sufficiente. Se nel tuo meeting di code review proponi 4 classi per gestire On/Off, potresti vedere facce perplesse e sentir pronunciare la fatidica frase: “Non complichiamoci la vita inutilmente”.

Template Method: la ricetta ereditabile (o il controllo-freak pattern)

Per gli architetti che vogliono dettare la ricetta, lasciando giusto qualche ingrediente a scelta dell’implementatore.

Che cos’è: Il Pattern Template Method è un modo elegante per dire: “Ti do uno scheletro di algoritmo, e tu riempi i dettagli mancanti a tuo piacere (ma attento a non uscire dal seminato)”. In pratica definisci in una classe base la sequenza di passi di un algoritmo, e lasci che siano le sottoclassi a implementare uno o più di questi passi. È un approccio invertito rispetto a Strategy: qui l’impalcatura è fissa (controllo centralizzato nella superclasse) e le varianti vengono fornite da metodi abstract/protetti che le sottoclassi override-ano. Se Strategy era composizione, Template Method è ereditarietà pura e dura.

Esempio culinario (semiserio): hai una classe base RicettaPasta con un metodo preparaPiatto() che fa: bollireAcqua(), aggiungiPasta(), cuoci(), scola(), condisci() – dove condisci() è un metodo abstract. Le sottoclassi SpaghettiAglioOlio implementa condisci() soffriggendo aglio e olio; PastaAlPesto implementa condisci() col pesto, e così via. Il template method preparaPiatto() è sempre lo stesso e non viene toccato dalle sottoclassi (guai a cambiare l’ordine di bollitura!), ma ciascuna sottoclasse può personalizzare alcuni passi. Nel mondo reale del software, pensa a quando hai una procedura generale con passi ben definiti, ma vuoi permettere ad implementazioni concrete di cambiarne qualcuno: ecco, quello è il momento Template Method.

Pro:

• Riutilizzo del codice: Lo scheletro dell’algoritmo sta una volta sola nella classe base. Niente duplicazioni dell’ordine delle operazioni nelle sottoclassi. Se devi cambiare la sequenza, lo fai in un punto unico.
• Controllo centrale: L’architettura rimane sotto controllo della superclasse. Questo garantisce che certi passi avvengano nell’ordine giusto, evitando che una sottoclasse sbadata faccia prima la frittata e poi rompa le uova.
• Facile da estendere in parte: Le sottoclassi possono concentrare la loro logica solo nei passi variabili. Non devono riscrivere tutto l’algoritmo, ma solo il necessario. Ideale per fornire default: magari la classe base implementa già qualche step comune, e le sottoclassi intervengono solo dove serve realmente differenziare.

Contro:

• Rigidità dell’algoritmo: Se devi cambiare la sequenza di passi (lo scheletro), devi modificare la classe base, toccando codice che influenza tutte le sottoclassi. Non è aperto/chiuso allo stesso livello di Strategy; qui il framework è un po’ più rigido.
• Dipendenza forte dall’ereditarietà: Si basa su classi base e override. Questo ti incastra in una gerarchia fissa. Se ad esempio vuoi combinare due varianti diverse, non puoi farlo semplicemente assemblando oggetti come faresti con Strategy, devi magari creare un’altra sottoclasse. Insomma, meno flessibile se le variazioni possibili non stanno bene in un unico albero di classi.
• Comprensione non immediata: Per chi legge il codice, capire il flusso completo richiede guardare sia la superclasse che la sottoclasse. “Chi chiama chi? Ah giusto, il metodo base invoca quello sovrascritto…”. Un novizio potrebbe preferire un approccio lineare (o uno Strategy) perché l’inversione di controllo tipica del Template Method può confondere all’inizio.

Difficoltà e sorprese nell’implementazione:

• Protezione dei passi: Decidere quali metodi rendere final (non sovrascrivibili) e quali abstract/override è cruciale. Se ne lasci troppi sovrascrivibili, qualcuno potrebbe alterare l’algoritmo in modi indesiderati. Se ne lasci troppo pochi, magari hai castrato la flessibilità. È un equilibrio delicato: dai un dito (di libertà) e c’è chi si prende il braccio (e stravolge il tuo algoritmo).
• Ordine delle chiamate: Attento a non chiamare metodi che le sottoclassi implementano dentro il costruttore della classe base (antipattern alert!). Classico errore: il costruttore della superclasse chiama un metodo pensato per essere overridden; la sottoclasse ancora non è inizializzata a dovere e boom, NullPointerException party.
• Visibilità: Spesso i metodi “hook” (quelli che le sottoclassi possono sovrascrivere) sono protected – usati solo all’interno dell’algoritmo. Bisogna documentare bene il loro scopo, perché dall’esterno della classe base non li vedi ma sono fondamentali per capire cosa succede. Inoltre, se il team non è disciplinato, c’è chi proverà a chiamare quei metodi protetti dall’esterno tramite hack riflessioni o amicizie indesiderate… eh, la disperazione fa brutti scherzi.

Quando usarlo: Quando hai una serie di classi che devono più o meno fare la stessa cosa, seguendo gli stessi passi generali, ma con alcune differenze di dettaglio in uno o pochi passi. Invece di duplicare la sequenza in tutte, la scrivi in un’unica classe base e lasci che ognuna personalizzi solo ciò che serve. Framework e librerie fanno largo uso di Template Method: ad esempio, quando devi definire tu solo certi pezzi di logica e il framework chiama il tuo codice al momento giusto (Hollywood principle: “don’t call us, we’ll call you”). Se stai scrivendo tu un mini-framework casalingo, Template Method può assicurare che gli utenti (i tuoi colleghi sviluppatori) estendano le classi base senza poter rompere la logica generale. In breve: usalo se vuoi centralizzare il controllo sul come si fa qualcosa, delegando il cosa si fa in quel passaggio specifico alle implementazioni concrete.

Quando evitarlo: Se ogni variante del tuo algoritmo potrebbe voler stravolgere anche la sequenza dei passi, Template Method inizierà a starti stretto. È pensato per varianti limitate, non per rivoluzioni. Inoltre, se puoi ottenere lo stesso risultato con una composizione di oggetti (Strategy o altri pattern) forse è meglio evitare di incatenarsi in gerarchie di classi. Un caso comico? Immagina di voler gestire il processo di fare il caffè con Template Method, ma un giorno ti chiedono anche di fare il tè. Se avevi hardcodato la sequenza riscalda acqua -> aggiungi caffè -> versa -> servi in classe base, ora per il tè dovresti modificare quella sequenza… oppure creare un’altra gerarchia parallela. Forse era più semplice avere strategie PreparazioneCaffe e PreparazioneTe intercambiabili, invece di un template monolitico. In generale, se senti che un pattern Strategy renderebbe il tutto più flessibile, probabilmente Template Method non è la scelta giusta (e viceversa).

Ah, e ovviamente, se già storci il naso all’idea di usare l’ereditarietà (team comp>inh alle porte), Template Method ti provocherebbe solo orticaria: in tal caso meglio evitarlo a priori.

Command: il comando a bacchetta (incapsula l’azione e via)

Chiamato anche “il pattern del telecomando”: schiaccia un bottone (invoca un metodo) e qualcosa succederà… altrove, in un’altra classe, magari più tardi.

Che cos’è: Il Pattern Command trasforma le azioni in oggetti. Invece di chiamare una funzione direttamente, incapsuli la richiesta in un oggetto comando separato. Questo ti permette di trattare quell’azione come un dato: passarla in giro, metterla in coda, annullarla, loggarla, ripeterla… Il Command funge da intermediario tra chi richiede qualcosa e chi esegue effettivamente quell’azione, isolando i due mondi. L’idea è: il Client crea un comando (es. OrdinePizzaCommand), lo consegna a un Invoker (es. il cameriere), il quale poi chiederà al Receiver appropriato (es. il pizzaiolo) di eseguire l’ordine al momento opportuno.

In pratica, invece di avere cameriere.eseguiOrdine("Margherita") che chiama direttamente pizzaiolo.cucina("Margherita"), con Command avrai qualcosa come: OrdinePizzaCommand("Margherita") – un oggetto che ha al suo interno il come eseguire l’azione (sa quale metodo chiamare sul Receiver, il pizzaiolo). Il cameriere invokerà esegui() sul comando quando sarà il momento, e il comando a sua volta chiamerà il ricevitore. Questo livello di indirection sembra superfluo all’inizio, ma apre porte interessanti: ad esempio, puoi mettere in fila tanti comandi e fare undo/redo (ogni comando può implementare anche un metodo undo() per fare l’azione inversa), oppure salvare lo storico dei comandi eseguiti, o inviarli su rete ad un server per eseguirli lato server mantenendo la stessa interfaccia client.

Pro:

• Decoupling totale: Il caller (invoker) non deve sapere nulla di cosa succede quando il comando viene eseguito, né chi lo eseguirà. Puoi cambiare l’esecutore o l’implementazione senza toccare il codice chiamante.
• Queue, log, undo facile: Trattando le richieste come oggetti, le puoi mettere in strutture dati. Vuoi una coda di task? Infila i Command in una lista e processali uno dopo l’altro. Vuoi implementare undo/redo? Ogni Command può salvare lo stato prima dell’esecuzione ed esporre undo(). Vuoi loggare tutte le operazioni fatte? Basta stampare o salvare da qualche parte la lista dei comandi eseguiti.
• Open/Closed per nuove operazioni: Aggiungere una nuova operazione non richiede modifiche ai caller esistenti; crei un nuovo comando concreto. Finché rispettano l’interfaccia comune (ad esempio un ICommand con un metodo execute()), il meccanismo generale rimane invariato.

Contro:

• Tante classi per poca cosa: Se l’operazione da compiere è semplice, creare un’intera classe Command può essere eccessivo. Ti potresti ritrovare con decine di classi anonime che fanno chiamate banali (OpenFileCommand che chiama solo File.open()…), una verbosità che alcuni faticano a giustificare.
• Gestione dello stato complicata (per undo): Se implementi l’undo, ogni comando deve sapere come annullare la propria azione e magari memorizzare lo stato precedente. Questo può complicare l’implementazione e far duplicare dati (o ti tocca introdurre anche il Memento pattern… e siamo a due pattern per risolvere un problema semplice!).
• Overdesign in agguato: Il rischio “patternite” qui è reale: puoi ritrovarti ad incapsulare qualunque chiamata in un comando anche quando non serve affatto. Se non hai bisogno di queue, log o undo, magari il Command è solo burocrazia inutile. In altre parole, non ogni click di bottone merita il suo Command class dedicato – a volte basta chiamare direttamente il metodo e bon.

Difficoltà e sorprese nell’implementazione:

• Architettura del Command invoker/receiver: Devi scegliere bene chi crea il comando e chi lo esegue. A volte il Invoker è un oggetto centralizzato (es. un gestore di eventi GUI), altre volte è distribuito. Capire dove instanziare i Command e dove far girare il loro execute() è cruciale. Se sbagli, rischi di complicare il flusso invece di semplificarlo (tipo: comandi lanciati a metà perché l’invoker non li gestisce come credi).
• Comandi parametrici: Ogni comando incapsula i propri parametri (es. quale file aprire). Se hai tanti parametri, il costruttore diventa lungo, oppure devi passare un oggetto contenitore. Considera builder o factory per istanziare comandi complessi, altrimenti costruirli a mano diventa noioso (e errore-prone).
• Rischio di memory leak: Se accumuli comandi in una lista di undo o li metti in coda senza attenzione, potresti dimenticare di rilasciare risorse o svuotare la coda. Se ogni comando pesa (magari tiene riferimenti a grosse porzioni di dati), la memoria potrebbe risentirne. Insomma, anche se li tratti come dati, i comandi non sono weightless. Attento a non inventarti una coda infinita di comandi non consumati… a meno che tu non stia implementando una blockchain 😜.

Quando usarlo: Il Command brilla quando hai bisogno di decoupling totale tra chi chiede e chi esegue, o vuoi flessibilità sul quando eseguire. Ad esempio:

• Undo/Redo: editor di testo, software di grafica – ogni azione dell’utente è un Command (scrivi testo, disegna linea) che puoi annullare invertendolo.
• Job queue: in sistemi concorrenti o distribuiti – trasformi operazioni in comandi e li metti in coda, magari eseguendoli in un thread pool, o ritentandoli in caso di fallimento.
• Macro: registrare una serie di azioni da rieseguire in seguito (ogni azione è un Command, li salvi in lista e poi riesegui in sequenza).

In generale, se il tuo problema richiede di parametrizzare richieste, loggarle, posticiparle o inoltrarle, Command è un grande alleato. Anche in architetture GUI spesso ogni pulsante è associato a un Command, così la logica del pulsante è separata dalla UI e puoi magari riutilizzarla altrove (es. stessa azione da menu, scorciatoia da tastiera, ecc.).

Quando evitarlo: Se hai un’applicazione semplice, lineare, dove le azioni utente chiamano funzioni e basta, introdurre i Command sarebbe ingiustificato. Un esempio ironico? Immagina un’applicazione calcolatrice in cui ogni singola operazione (somma, sottrai, cancella) è un oggetto Command separato. Bello… per studiarci i pattern, meno bello quando ti accorgi che hai scritto il triplo del codice di una calcolatrice normale e l’unica feature in più è che puoi fare undo sull’ultimo numero inserito (cosa che potevi fare anche salvando una variabile). In sintesi: se non guadagni realmente in flessibilità o riuso, rischi di aggiungere solo indirection inutile. Non usare il pattern solo per poter dire che lo hai usato! – (questo consiglio vale sempre, ma col Command è particolarmente facile cadere nella trappola).

Conclusione: Sopravvivere alla Patternite acuta

Abbiamo scherzato (ma non troppo) su Strategy, State, Template Method, Command e sui loro pregi e difetti. Il filo conduttore? Sono strumenti potenti, ma come ogni strumento vanno usati con criterio. La patternite acuta è quella malattia professionale che colpisce alcuni sviluppatori dopo aver letto il libro della Gang of Four: all’improvviso vedono pattern da applicare ovunque, anche per aprire una porta (Singleton Door Opener Pattern™, perché no?). Il risultato? Codice over-engineered, inutilmente complicato, che fa scappare i colleghi come davanti a un sistema legacy scritto in COBOL

Come non farsi prendere dalla patternite? Ecco qualche consiglio finale (ironico ma sincero):

• Conosci i pattern, ma dimenticatene fino al bisogno: imparali per sapere che esistono, ma non pensare “oggi devo implementare un pattern X a tutti i costi”. Pensa prima al problema, non alla soluzione preconfezionata. Se sembra che un certo pattern calzi a pennello, allora tiralo fuori dal cappello. Altrimenti, lascia il cappello pieno.
• KISS – Keep It Simple, Sviluppatore: se la soluzione semplice funziona ed è mantenibile, non complicarla solo per sfoggiare design pattern come medaglie. Il codice dovrebbe essere scritto per essere capito, non per impressionare la commissione del Politecnico.
• Refactoring come bussola: un buon momento per applicare un pattern è durante il refactoring. Se vedi che il codice sta crescendo in complessità (troppi if simili? troppi casi speciali?), allora ricorda “ah, esiste un pattern che sistemerebbe questo pasticcio!”. Prima scrivi qualcosa che funziona in modo chiaro, poi valuta se generalizzarlo con un pattern.
• Divertiti (responsabilmente): Sperimentare con i pattern è divertente e formativo. Fallo in progetti personali, nelle kata, o in parti circoscritte del codice. Non azzardare una rivoluzione a pattern in un progetto critico senza condividere col team: potresti ritrovarti solo al fronte 😅.

In definitiva, i design pattern come Strategy, State, Template Method, Command sono alleati preziosi, ma non devono diventare i padroni di noi sviluppatori. Usali quando servono davvero e tieni sempre un occhio critico: a volte una soluzione più semplice è dietro l’angolo, e l’unica strategia vincente è il buon senso.

E ricordate, come disse un saggio architetto software (forse in una retrospettiva after-hour): “Il miglior design pattern è quello che risolve il problema senza crearne di nuovi.”

Buon coding!