Mining Frequent patterns without Candidate Generation De Faveri Alessandro Matricola 795135.
Design patterns - parte 1
-
Upload
fabio-armani -
Category
Technology
-
view
885 -
download
0
description
Transcript of Design patterns - parte 1
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