Raffaeu mi porge un (gradito) complimento, che è però anche un interessante spunto per una riflessione. BTW, niente di nuovo all'orizzonte, perchè è una riflessione che ho già ampiamente esposto durante il tutorial dei Community Days, ma ritengo comunque interessante estenderla.
Un moderno emulo di Gian Battista Vico non esiterebbe ad includere il seguente scenario tra i "corsi e ricorsi storici": quando un dev entra in contatto con i [design|architecture|refactoring|vattelapesca] pattern la reazione è, tipicamente, una delle seguenti:
- Il dev diventa un "pattern fanatic": parla continuamente di pattern e li infila dappertutto (un divertente "asse cronologico"" di questo scenario 1 è disponibile in [Nilsson, ADDD.NET])
- Il dev li rifiuta in quanto (scegliere il proprio "best pick"): inutili, "acquacaldosi", eccessivamente astratti, ...
Ma i pattern rappresentano (o aggiungono) davvero un valore? Parliamone :-)
Partendo dal presupposto che la soluzione sia basata sul FX .NET o comunque implementata utilizzando un linguaggio che aderisca al paradigma object oriented, quando "progettiamo" ("to design" in inglese) un sistema dovremmo farlo tenendo *bene* in mente i requisiti e i princìpi di progettazione OO; i requisiti rappresentano ciò che il sistema deve fare e per un architetto sono "sacri ed inviolabili" giacchè:
- Se funzionali, sono di competenza di un analista che ha *sicuramente* una comprensione del dominio superiore alla nostra
- Se non funzionali, sono frutto di qualche accordo "contrattuale" (es: SLA)
Ergo, non è certo inclusa nella "carta dei diritti" di un architetto la possibilità di modificarli a propria volontà. Per quanto riguarda i requisiti, inoltre, la norma ISO9126 svolge un ottimo lavoro di categorizzazione e rende evidente la natura di requisito di "topic" (troppo) spesso trascurati quali (a puro titolo di esempio ed in rigoroso ordine alfabetico): interoperability, security e testability.
Affrontato il "cosa", dedichiamoci al "come": un buon architetto è un uomo (o donna) di... Sani princìpi :-) Dal primordiale "...you must find pertinent objects..." ai vari DIP/LSP/OCP/SRP/... essi sono il "razionale" che ci deve guidare nelle nostre scelte progettuali a qualunque livello di dettaglio. Se anche i pattern non esistessero, questi principi ci permetterebbero in ogni caso di scrivere del "buon codice". Ma i pattern esistono, quindi... Che fare? Semplicemente, non vivere "inseguendoli" (i pattern). Non "snobbiamoli/ignoriamoli", ma impariamo ad evere un approccio rilassato nei loro confronti. Affrontiamo un problema alla volta e, se avessimo l'evidenza che quello che stiamo affrontando sia risolto da un pattern, usiamolo senza remore: nessuno oggi si inventa una tecnica risolutiva per il problema "gestione di un documento strutturato" quando esiste Composite.
Spesso però confondiamo una congettura con una evidenza, e dovremmo invece migliorare la nostra capacità di riconoscere le congetture. Di fronte ad una congettura, trasformiamoci in Pollicino ed usiamo requisiti e principi come "traccia" per affrontare lo scenario: facendolo sistematicamente realizzeremo comunque una soluzione strutturalmente simile a "qualche" pattern, nel qual caso valuteremo se un "refactoring to quel pattern" possa portare del valore aggiunto, altrimenti... Squadra che vince non si cambia :-)
In (estrema e quindi approssimativa) sintesi: i pattern possono essere un "fine" (refactoring to pattern) od un "mezzo" (abbiamo un problema *chiaramente* risolto da un pattern in modo ottimale), e a volte "il fine giustifica i mezzi". Di certo non "sono" un valore, anche se "hanno" valore, giacchè sono "soluzioni *dimostrate* funzionanti a problemi ricorrenti".