Design Patterns Applied
Andrea Saltarello
Software Architect – Managed Designs S.r.l.
http://blogs.ugidotnet.org/pape
Sponsor
Parliamo di…
• Architettura e OOD
• Design Pattern
• Enterprise Application design
Cosa è il Design?
• E’ la fase di progettazione di un sistema.
• La progettazione è la fase nella quale
vengono presi in considerazione tutti i
requisiti non funzionali (HA, scalabilità,
integrabilità, …) del sistema:
– l’analisi si concentra su cosa debba fare il sistema
– il design si concentra su come debba farlo
• Dobbiamo concepire l’architettura del
nostro sistema.
Cosa è l’Architettura?
Secondo la definizione ANSI/IEEE Std
1471-2000:
“L’organizzazione basilare di un sistema, rappresentato
dalle sue componenti, dalle relazioni che esistono tra
di loro e con l’ambiente circostante, e dai principi che
governano la sua progettazione e evoluzione."
Object Oriented Design 101
Come procedere? Secondo l’autorevole “Gangs of
Four”:
You must find pertinent objects, factor them into classes at
the right granularity, define class interfaces and inheritance
hierarchies, and estabilish key relationships among them.
In pratica, dobbiamo rielaborare il frutto dell’analisi
tenendo in considerazione le possibilità offerte
dall’orientamento all’oggetto. Un esempio? I
Design Pattern! 
Design Patterns Defined
"Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core
solution to that problem, in such a way that
you can use the solution a million times over,
without ever doing it the same way twice.“
Christoper Alexander
A Pattern Language, 1977
OOD: Design Patterns
I pattern costituiscono soluzioni
sperimentate a problemi concreti,
utilizzabili in contesti applicativi differenti.
Possiamo pensare ad un pattern come alla
descrizione, soluzione ed applicazione di
un problema comune fattorizzato in una
soluzione elegante.
Design Patterns 101
Proviamo ad ipotizzare un pattern:
dobbiamo isolare un problema ricorrente,
e formulare una soluzione generalmente
valida.
Facile! Pronti? Via!
Quanti interisti ci sono in sala? 
Serie A, stagione 2004/2005
CHIEVO-INTER
2-2
X
INTER-PALERMO
1-1
X
ATALANTA-INTER
2-3
2
INTER-PARMA
2-2
X
ROMA-INTER
3-3
X
INTER-UDINESE
3-1
1
MILAN-INTER
0-0
X
LECCE-INTER
2-2
X
INTER-LAZIO
1-1
X
FIORENTINA-INTER
1-1
X
INTER-BOLOGNA
2-2
X
CAGLIARI-INTER
3-3
X
INTER-JUVENTUS
2-2
X
Ecco il problema
ricorrente! 
Ora dobbiamo
formalizzare il
pattern
Design Patterns defined
Un pattern è contraddistinto da quattro
elementi:
• Nome: è utile per descrivere la sua funzionalità in una
o due parole.
• Problema: descrive la classe di problemi affrontata
dal pattern
• Soluzione: descrive in modo astratto come il pattern
risolve il problema. Descrive gli elementi che
compongono il design, le loro responsabilità e le
collaborazioni
• Conseguenze: sono importanti per poter valutare i
costi-benefici dell'utilizzo del pattern
“Utopia” pattern defined
Proviamo a formulare il pattern
• Nome: Utopia
• Problema: subirne sistematicamente uno in
meno degli altri
• Soluzione: Difensori decenti, attenzione e
all’occorrenza tanti calci nel…  [diagramma]
• Conseguenze: l’applicazione del pattern può
comportare la vittoria di Scudetto/Champion’s
League, in particolar modo in combinazione a
CooperativePlay
Design Patterns unleashed
Il Testo di riferimento è:
Design Patterns: Elements of Reusable
Object-Oriented Software di Erich Gamma,
Richard Helm, Ralph Johnson e John
Vlissides
Sono loro la “Gang of Four”
Design Patterns applied
I design pattern ci aiutano a risolvere
problemi di tutti i giorni. Esempi:
• Ricordate VB6? La default instance si ottiene
con Singleton
• Ricordate ADODB? La dipendenza dal provider
si elimina con Factory Method
Design Patterns applied: Singleton
Problema: Ensure a class has only one
instance and provide a global point of
access to it.
Design Patterns applied: Factory method
Problema: Define an interface for creating
an object, but let subclasses decide which
class to instantiate. Factory Method lets a
class defer instantiation to subclasses.
Dice il saggio…
Non dobbiamo pensare ai pattern come
a dogmi, bensì come alle centurie di
Nostradamus: vanno interpretati 
Design Patterns applied
Basta con gli esempi sintetici: mettiamo i
pattern alla prova in una applicazione
reale!
Ipotizziamo una applicazione enterprise con
i “soliti” requisiti:
• DB-independent (tecnologia e struttura)
• GUI-independent (almeno Win e Web)
Enterprise application design
Per soddisfare i requisiti, optiamo per una
architettura a 3 livelli:
• Concentrare la logica applicativa nel
business layer rende agevole
implementare GUI eterogenee
• Isolare l’accesso ai dati in un DAL (Data
Access Layer) permette di disaccoppiare
la business logic dal DB
OOD: Business Entities
Per disaccoppiare l’applicazione dalla
struttura del DB, modelliamo come classi
le strutture dati gestite.
Ci ispiriamo al pattern Domain Model [P of
EAA, 116]
“Domain Model” pattern
An object model of the domain that incorporates
both behavior and data.
At its worst business logic can be very complex.
Rules and logic describe many different cases
and slants of behavior, and it's this complexity
that objects were designed to work with. A
Domain Model creates a web of interconnected
objects, where each object represents some
meaningful individual, whether as large as a
corporation or as small as a single line on an
order form.
OOD: il data layer
Il DAL incapsula l’accesso al database, al
fine di disaccoppiare la business logic
dalla tecnologia di storage. Utilizziamo il
pattern Table Data Gateway [P of EAA,
144]
“Table Data Gateway” pattern
An object that acts as a Gateway to a database
table. One instance handles all the rows in the
table.
A Table Data Gateway holds all the SQL for
accessing a single table or view: selects, inserts,
updates, and deletes. Other code calls its
methods for all interaction with the database.
“Table Data Gateway” (TDG) revised
La nostra applicazione disporrà di un DAL
specifico per ogni DBMS supportato; definiamo
quindi un TDG astratto (es: interfaccia) che sarà
implementato dai DAL.
La business logic riceverà un riferimento al DAL
attivo, che sarà attivato da una Abstract
Factory [GoF, 87]
La formulazione accademica di TDG riceve in
ingresso i valori dei campi come parametri
indipendenti: per rinforzare l’indipendenza dalla
struttura del DB, noi utilizzeremo come
parametri istanze delle business entities
Domain Model strikes back
Che succede se chiediamo al DAL una
ricerca per codice/chiave e l’elemento
corrispondente non esiste nel DB?
Restituire un null non è una soluzione,
perché “rompe” il polimorfismo.
Usiamo il pattern Special Case [P of EAA,
496]
“Special Case” pattern
A subclass that provides special behavior for
particular cases.
Nulls are awkward things in object-oriented
programs because they defeat polymorphism.
(…) Instead of returning null, or some odd value,
return a Special Case that has the same
interface as what the caller expects
DAL: un approccio futuristico
Se avessimo a disposizione un ORM
(ObjectSpaces… Se ci sei, batti un colpo!
) potremmo usare il pattern Adapter
[GoF, 139] per trasformarne l’interfaccia in
quella del DAL/TDG.
OOD: Business Layer
Per prima cosa, dobbiamo esporre alla GUI
le funzionalità OLTP offerte dallo strato
dati.
In pratica, implementiamo un Mapper [P of
EAA, 473] che funga da Gateway [P of
EAA, 466] verso il DAL
OOD: Biz Logic vs. DAL
Un modo interessante per disaccoppiare le
classi di business dal corrispettivo DAL
consiste nell’usare il pattern Inversion of
Control (IoC), ossia una applicazione del
pattern Plugin [P of EAA, 499]
“Inversion of Control” pattern
IoC è anche definito Dependency
Injection, e consiste nel far pubblicare ad
una classe una API che permetta al
contesto di esecuzione di impostarne a
runtime le dipendenze. E’ utile per:
• Iniettare mock object
• Utilizzare light container per configurare
l’applicazione
Pattern vs. Idiomi
• Un pattern insiste sul paradigma
• Un idioma insiste sulla tecnologia
Es: Observer vs. Delegate/eventi
Riferimenti
Docs:
• IoC:
http://www.martinfowler.com/articles/injection.html
Pattern:
• GoF
http://www.dofactory.com
• P of EAA
http://www.martinfowler.com/eaaCatalog/index.html
Tool:
• NSpring:
http://sourceforge.net/projects/nspring
Links
http://www.ugidotnet.org
http://forum.ugidotnet.org
http://mobile.ugidotnet.org