Feed RSS

Pattern o non pattern?

Andrea Saltarello — Fri, 18 Jul 2008 12:12:47 GMT

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".

Technorati Tag: design pattern,refactoring to patterns,software architecture

Community Days 2008: my 2 (euro) cents

Andrea Saltarello — Fri, 11 Jul 2008 16:16:51 GMT

Durante la (ancora una volta ho scoperto piacevolmente che pu� funzionare) Q&A finale ho capito che il plurale del termine Community non � Communities ma Community...solo pi� grossa. Esattamente come due stormi formano...uno stormo. Da queste piccole riflessioni possono nascere grandi cose.

E' una affermazione che esprime fedelmente il mio pensiero, e che IMVHO richiede una profonda sensibilit� per essere pensata e formulata. Non mi stupisce che l'autore sia Omar

Da parte mia... Grazie a tutti: erano anni che non provavo una emozione simile, e questa volta non ho nemmeno dovuto vestirmi come "una trottola" :-)

Technorati Tag: Community Days,UGIdotNET

Community Days: last minute

Andrea Saltarello — Mon, 07 Jul 2008 20:04:36 GMT

Ok, Daniele non si sar� (ma ha buoni motivi ed ottimi sostituti) e mercoledi sera si va a cena (accodatevi al thread sul forum/NG per aderire cos� prenotiamo posti sufficienti).

Gli annunci "last minute" per� non finiscono qui. Osserviamo la seguente sequenza:

Ipotizzando che:

Create(an order) sia invocato da un controller implementato in una applicazione MVC basata sul framework MVC di Microsoft
Il data context sia iniettato usando Unity, il container IoC della Enterprise Library 4.0
Parte delle business rules siano implementate usando il Validation Application Block della Enterprise Library
L'ordine sia effettivamente persistito usando Sua Maest� NHibernate
L'applicazione sia coperta da test implementati con MSTest
Buona parte di quanto esposto sia stato implementato (tempo permettendo) *anche* usando lo stack di CastleProject (Monorail+Windsor) -del quale gi� Mauro parler� abbondantemente nella sua sessione- nonch� NUnit per i test

Beh, allora avremmo una idea del contenuto del tutorial "Implementare architetture layered" che abbiamo aggiunto in agenda.

Ha ragione Simone: questi CD sono orientati al "nuovo". In effetti apparentemente in giro non c'� (ancora) nulla di equivalente, in attesa del remake de "L'attacco dei Cloni" <g> Ci vediamo mercoledi?

UPDATE: Mi dicono dalla regia che (testuali parole) "Salvo imprevisti le sessioni saranno registrate"

Technorati Tag: Community Days,Enterprise Library,IoC,MVC,UGIdotNET