Upload
fabio-armani
View
890
Download
0
Embed Size (px)
DESCRIPTION
The design patterns are recurring solutions to common problems in software design. The design patterns in computer science were formally described for the first time in the book "Design Patterns: Elements of Reusable Object-Oriented Software", whose authors are often called the Gang of Four, GoF or Go4.
Citation preview
PATTERN ARCHITETTRALI
Pa#ern è un termine inglese che può essere trado>o, a seconda del contesto, con disegno, modello, schema, schema ricorrente e, in generale, può essere u@lizzato per indicare una regolarità che si riscontra all'interno di un insieme di oggeD osserva@ oppure la regolarità che si osserva nello spazio e/o nel tempo in determina@ fenomeni dinamici.
fabio.armani
Overview
• Analysis pa>erns • Architectural pa>erns • Design pa>erns • Enterprise pa>erns • GRASP pa>erns • Implementa@on pa>erns • J2EE Core pa>erns • SCM pa>erns
Overview
• Design Pa>ern – Stru>ura di un pa>ern – Classificazione dei design pa>ern
Design Pa>erns • I design pa>erns sono soluzioni ricorren@ a problemi comuni nel
campo del soTware design • I design pa>erns in ambito informa@co vengono formalmente
descriD per la prima volta nel libro Design Pa*erns: Elements of Reusable Object-‐Oriented So<ware, i cui autori vengono spesso chiama@ la Gang of Four o GoF o Go4
• I design pa>erns NON rappresentano la proge>azione completa di una soluzione, che può essere trasformata dire>amente in codice
• Essi rappresentano piu>osto la descrizione di come risolvere un problema che può sorgere in differen@ situazioni. I design pa>erns sono una sorta di template rispe>o alla soluzione di problemi ricorren@ in determina@ campi dell’informa@ca
Design Pa>erns • I design pa>erns possono velocizzare il processo di sviluppo del
soTware fornendo paradigmi di programmazione prova@ e testa@ • I design pa>erns forniscono soluzioni generali, documentate in un
formato che non richiede specifiche legate ad un par@colare problema
• I design pa>erns cos@tuiscono un veicolo per la comunicazione inerente la proge>azione e le archite>ure soTware
Design Pa>erns > libri
Stru>ura di un pa>ern • Un pa>ern può avere una precisa stru>ura che lo descrive
Stru>ura di un pa>ern • nome: iden@fica il pa>ern e deve rappresentarlo il più
possibile (es: Factory) • descrizione: una breve descrizione dell’obbieDvo del pa>ern,
corrispondente in quasi tuD i casi al “intent” del libro di GoF • problema: rappresenta la descrizione della situazione alla
quale si può applicare il pa>ern • soluzione: rappresenta la descrizione degli elemen@ cos@tu@vi
del proge>o con le loro relazioni, senza però scendere nei de>agli implementa@vi. Quello che si vuole descrivere infaD è un problema astra>o e la rela@va configurazione di elemen@ ada>a a risolverlo
Stru>ura di un pa>ern • stru5ura del pa5ern: diagramma di classi in UML della
stru>ura generica del pa>ern • applicazione del pa5ern: offre un diagramma UML delle classi
del problema, presenta l’abbinamento delle classi del problema con le classi che descrivono la stru>ura conce>uale del pa>ern, descrive l’implementazione del il codice Java, e presenta e commenta gli output dell’esecuzione
• osservazioni sull’implementazione in Java: presenta gli aspeD par@colari che riguardano l’implementazione del pa>ern in Java
Stru>ura di un pa>ern • conseguenze: i risulta@ e i vincoli derivan@ dall’applicazione
del pa>ern. Essi sono fondamentali, in quanto possono risultare determinan@ nella scelta del pa>ern stesso: le conseguenze comprendono considerazioni legate alle risorse computazionali (tempo e memoria), possono descrivere le implicazioni del pa>ern con alcuni linguaggi di programmazione e l’impa>o di quest’ul@mo con il resto del proge>o
Classificazione dei design pa>ern
• Ci sono diversi criteri per classificare i design pa>erns, i più comuni dei quali sono quelli che evidenziano il @po di problema che si cerca di risolvere
• Nel suo libro, la Gang Of Four individuò 23 design pa>ern suddivisi in tre categorie. : stru>urali, creazionali e comportamentali
PATTERN CREAZIONALI
Classificazione dei design pa>ern
• Pa*ern Creazionali: rendono i componen@ del sistema che usano determina@ oggeD indipenden@ da come tali oggeD sono sta@ crea@, compos@ e rappresenta@.
• I pa>ern creazionali nascondono i costru>ori delle classi e me>ono al loro posto dei metodi creando un’interfaccia.
• In questo modo si possono u@lizzare oggeD senza sapere come sono implementa@.
Pa>ern creazionali • L'Abstract factory (le>eralmente, "fabbrica astra>a") fornisce
un'interfaccia per creare famiglie di oggeD connessi o dipenden@ tra loro, in modo che non ci sia necessità da parte degli u@lizzatori di specificare i nomi delle classi concrete all'interno del proprio codice.
• Il Builder ("costru>ore") separa la costruzione di un ogge>o complesso dalla sua rappresentazione, in modo che il processo di costruzione stesso possa creare diverse rappresentazioni.
• Il Factory method ("metodo fabbrica") fornisce un'interfaccia per creare un ogge>o, ma lascia che le so>oclassi decidano quale ogge>o istanziare.
Pa>ern creazionali • La Lazy ini?aliza?on ("inizializzazione pigra") è la taDca di istanziare un
ogge>o solo nel momento in cui deve essere usato per la prima volta. È u@lizzato spesso insieme al pa>ern factory method.
• Il Prototype ("proto@po") perme>e di creare nuovi oggeD clonando un ogge>o iniziale, o proto@po.
• Il Singleton ("singole>o") ha lo scopo di assicurare che di una classe possa essere creata una sola istanza.
PATTERN STRUTTURALI
Classificazione dei design pa>ern
• Pa*ern Stru*urali: perme>ono di riu@lizzare oggeD esisten@, u@lizzando l’ereditarietà e il polimorfismo per comporre interfacce diverse o implementazioni di una stessa interfaccia.
• I pa>ern stru>urali riguardano il modo in cui più oggeD sono collega@ tra loro per formare stru>ure complesse.
Pa>ern stru>urali • L'Adapter ("ada>atore") converte l'interfaccia di una classe in una
interfaccia diversa. • Bridge ("ponte") perme>e di separare l'astrazione di una classe dalla sua
implementazione, per perme>ere loro di variare indipendentemente. • Il Composite ("composto"), u@lizzato per dare la possibilità all'u@lizzatore
di manipolare gli oggeD in modo uniforme, organizza gli oggeD in una stru>ura ad albero.
• Il Container ("contenitore") offre una soluzione alla ro>ura dell'incapsulamento per via dell'uso dell'ereditarietà.
• Il Decorator ("decoratore") consente di aggiungere metodi a classi esisten@ durante il run-‐@me (cioè durante lo svolgimento del programma), perme>endo una maggior flessibilità nell'aggiungere delle funzionalità agli oggeD.
• Extensibility ("estendibilità")
Pa>ern stru>urali • Il Façade ("facciata") perme>e, a>raverso un'interfaccia più semplice,
l'accesso a so>osistemi che espongono interfacce complesse e diverse tra loro.
• Flyweight ("peso piuma"), che perme>e di separare la parte variabile di una classe dalla parte che può essere riu@lizzata.
• Proxy fornisce una rappresentazione di un ogge>o di accesso difficile o che richiede un tempo importante per l’accesso o creazione. Il Proxy consente di pos@cipare l’accesso o creazione al momento in cui sia davvero richiesto.
• Pipes and filters ("condoD e filtri") • Private class data ("da@ di classe priva@")
PATTERN COMPORTAMENTALI
Classificazione dei design pa>ern
• Pa*ern Comportamentali: riguardano l’assegnazione di responsabilità agli oggeD, incapsulando il comportamento in un ogge>o e delegando ad esso determinate richieste.
• I pa>ern comportamentali forniscono soluzione alle più comuni @pologie di interazione tra gli oggeD
Pa>ern comportamentali • Chain of Responsibility ("catena di responsabilità") diminuisce
l'accoppiamento fra l'ogge>o che effe>ua una richiesta e quello che la soddisfa, dando a più oggeD la possibilità di soddisfarla
• Il Command ("comando") perme>e di isolare la porzione di codice che effe>ua un'azione dal codice che ne richiede l'esecuzione.
• Event Listener ("ascoltatore di even@") • Hierarchical Visitor ("visitatore di gerarchia") • Interpreter ("interprete") dato un linguaggio, definisce una
rappresentazione della sua gramma@ca insieme ad un interprete che u@lizza questa rappresentazione per l'interpretazione delle espressioni in quel determinato linguaggio.
• L'Iterator ("iteratore") risolve diversi problemi connessi all'accesso e alla navigazione a>raverso gli elemen@ di una stru>ura da@, senza esporre i de>agli dell'implementazione e della stru>ura interna del contenitore.
Pa>ern comportamentali • Il Mediator ("mediatore") si interpone nelle comunicazioni tra oggeD, allo
scopo di aggiornare lo stato del sistema quando uno qualunque di essi comunica un cambiamento del proprio stato.
• Il design pa>ern Memento ("promemoria") è l'operazione di estrarre lo stato interno di un ogge>o, senza violarne l'incapsulazione, e memorizzarlo per poterlo ripris@nare in un momento successivo.
• L'Observer ("osservatore") definisce una dipendenza uno a mol@ fra oggeD diversi, in maniera tale che se un ogge>o cambia il suo stato, tuD gli oggeD dipenden@ vengono no@fica@ del cambiamento avvenuto e possono aggiornarsi.
• Single-‐serving Visitor
Pa>ern comportamentali • State ("stato") perme>e ad un ogge>o di cambiare il suo comportamento
al cambiare di un suo stato interno. • Lo Strategy ("strategia") è u@le in quelle situazioni dove è necessario
modificare dinamicamente gli algoritmi u@lizza@ da un'applicazione. • Il Template method ("metodo schema") perme>e di definire la stru>ura di
un algoritmo lasciando alle so>oclassi il compito di implementarne alcuni passi come preferiscono.
• Il Visitor ("visitatore") perme>e di separare un algoritmo dalla stru>ura di oggeD compos@ a cui è applicato, in modo da poter aggiungere nuovi comportamen@ senza dover modificare la stru>ura stessa.
Design Pa>erns : GoF • The Sacred Elements of the Faith
Design Pa>erns everywhere
PATTERN CREAZIONALI
SINGLETON Gof pag. 117
Singleton
Descrizione • Il Singleton è un design pa>ern creazionale che ha lo scopo di
garan@re che di una determinata classe venga creata una e una sola istanza, e di fornire un punto di accesso globale a tale istanza.
Singleton
Esempio • Un applica@vo deve istanziare un ogge>o che ges@sce una
stampante. Questo ogge>o deve essere unico, vale dire, deve esserci soltanto una sola istanza di esso, altrimen@, potrebbero risultare dei problemi nella ges@one della risorsa.
• Il problema è la definizione di una classe che garan@sca la creazione di un'unica istanza all’interno del programma.
Singleton
Problema • Bisogna garan@re che la classe abbia un’unica istanza,
accessibile a>raverso un unico punto di ingresso alla classe stessa.
• Tipicamente questo si verifica quando la classe man@ene informazioni che devono essere condivise da più par@ dell’applicazione e non è corre>o oppure non è efficiente che queste informazioni siano duplicate
Singleton
Soluzione • Il “Singleton” pa>ern definisce una classe della quale è
possibile la istanziazione di un unico ogge>o, tramite l’invocazione a un metodo della classe, incaricato della produzione degli oggeD.
• Le diverse richieste di istanziazione, comportano la res@tuzione di un riferimento allo stesso ogge>o.
Singleton
Soluzione • Si rende il costru>ore della classe privato, in modo che non
sia possibile creare dire>amente istanze di tale classe. • La classe viene dotata di un metodo sta?c per o>enere
un’unica istanza, che viene memorizzata in un campo sta?c privato della classe stessa. Tu>avia possono esserci alcune variazioni a tale soluzione: – l’istanza può essere creata all’inizializzazione del programma, oppure la prima volta che viene richiesta
– l’istanza può appartenere a una so>o classe della classe singleton (come accade nel Factory Method)
Singleton
Stru*ura
Singleton
Schema del modello • Si presenta di seguito una delle implementazioni più semplici
del Singleton:
Singleton
PartecipanJ • Singleton: classe PrinterSpooler.
– Definisce un metodo getInstance che res@tuisce un riferimento alla unica istanza di se stessa.
– E’ responsabile della creazione della propria unica istanza.
Singleton
Implementazione • L'implementazione più semplice di questo pa>ern prevede
che la classe singleton abbia un unico costru>ore privato, in modo da impedire l'istanziazione dire>a della classe.
Singleton
Implementazione
Singleton
Implementazione mulJ-‐thread • In applicazioni mul@-‐thread l'u@lizzo di questo pa>ern con la
lazy ini?aliza?on richiede un'a>enzione par@colare: se due thread tentano di eseguire contemporaneamente il costru>ore quando la classe non è stata ancora istanziata, devono entrambi controllare se l'istanza esiste e soltanto uno deve creare la nuova istanza.
Singleton
Sincronizzazione esplicita • Il modo più semplice per implementare una versione thread-‐
safe è quello di usare un meccanismo di sincronizzazione come quello fornito dalla parola chiave synchronized di Java.
• Tu>avia questo approccio è inefficiente: infaD la sincronizzazione è u@le solo per la prima inizializzazione, e cos@tuisce un inu@le overhead nelle successive chiamate al metodo getter.
Singleton
Sincronizzazione esplicita
Singleton
Sincronizzazione implicita • In alcuni linguaggi è possibile evitare l'overhead di
sincronizzazione sfru>ando quelle peculiarità della lazy ini?aliza?on che consentono di assicurarsi la presenza del singleton in memoria all'a>o del suo u@lizzo.
• Le modalità specifiche possono variare da linguaggio a linguaggio; ad esempio, in Java è possibile sfru>are il fa>o che l'inizializzazione di una classe ed il suo caricamento in memoria, quando avvengono, sono operazioni thread-‐safe che comprendono l'inizializzazione di tu>e le variabili sta@che (a>ribu@) della classe stessa.
Singleton
Sincronizzazione implicita
Singleton
Conseguenze • Con il singleton si ha che:
– l’accesso alla classe è controllato e avviene a>raverso l’unica istanza che può essere creata
– non occorre introdurre variabili globali per accedere all’unica istanza
– è semplice estendere la classe singleton senza modificare il codice che usa
– è semplice passare da una singola istanza a più istanze
Singleton
CriJche • Alcuni autori hanno cri@cato il pa>ern Singleton, osservando
che, con opportune modifiche stru>urali, una istanza singola può entrare più efficacemente a far parte dell'Ambiente globale dell'applicazione
ENTERPRISE PATTERN
Enterprise Pa>erns • Pa>erns of Enterprise Applica@on Architecture • Core J2EE Pa>erns • Integra@on Pa>erns
Enterprise Pa>erns > books
Core J2EE Pa>erns • Presenta@on Tier • Business Tier • Integra@on Tier
Core J2EE Pa>erns • Presenta@on Tier
– Applica@on Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercep@ng Filter – Service To Worker – View Helper
Core J2EE Pa>erns • Business Tier
– Applica@on Service – Business Delegate – Business Object – Composite En@ty – Service Locator – Session Façade – Transfer Object (DTO) – Transfer Object Assembler – Value List Handler
Core J2EE Pa>erns • Integra@on Tier
– Data Access Object (DAO) – Domain Store – Service Ac@vator – Web Service Broker
Presenta@on Tier Pa>ern – Applica@on Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercep@ng Filter – Service To Worker – View Helper
FRONT CONTROLLER PoEAA -‐ pag. 117
FRONT CONTROLLER
FRONT CONTROLLER !
Front Controller
Descrizione • Consente di ges@re il mapping logico delle risorse
Front Controller
Problema • Si vuole fornire un punto di accesso centralizzato per la
ges@one delle richieste al livello dello strato di presentazione, in modo da sparare la logica di presentazione da quella di processamento delle richieste stesse.
• Inoltre si vuole evitare di avere del codice duplicato e si vuole applicare una logica comune a più richieste.
Front Controller
Soluzione • Si u@lizza un Front Controller come punto di accesso iniziale
per ges@re tu>e le richieste connesse tra loro. • Il Front Controller centralizza la logica di controllo che
dovrebbe altrimen@ essere replicata per ogni richiesta.
Front Controller Avoid: • Physical Resource Mapping • Unhandled Mapping in Multyplexed Resource Mapping
strategy • Logging of Arbitrary HTTTP Parameters • Duplicating Common Logic Across Multiple Front Controllers
Use to Implement: • Logical Resource Mapping • Session Management • Audit Logging
Avoid: • Invoking Commands Without Sufficient Authorization
Front Controller
Front Controller
Front Controller
Front Controller
Conseguenze • Le conseguenze che derivano dall’u@lizzo di tale pa>ern sono:
– centralizzazione del controllo – miglioramento della riusabilità – miglioramento della manutenibilità – separazione dei ruoli all’interno dell’applicazione