design patterns - parte 1
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.TRANSCRIPT
![Page 1: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/1.jpg)
![Page 2: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/2.jpg)
PATTERN ARCHITETTRALI
![Page 3: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/3.jpg)
![Page 4: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/4.jpg)
![Page 5: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/5.jpg)
![Page 6: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/6.jpg)
![Page 7: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/7.jpg)
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.
![Page 8: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/8.jpg)
fabio.armani
![Page 9: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/9.jpg)
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
![Page 10: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/10.jpg)
Overview
• Design Pa>ern – Stru>ura di un pa>ern – Classificazione dei design pa>ern
![Page 11: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/11.jpg)
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
![Page 12: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/12.jpg)
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
![Page 13: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/13.jpg)
Design Pa>erns > libri
![Page 14: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/14.jpg)
Stru>ura di un pa>ern • Un pa>ern può avere una precisa stru>ura che lo descrive
![Page 15: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/15.jpg)
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
![Page 16: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/16.jpg)
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
![Page 17: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/17.jpg)
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
![Page 18: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/18.jpg)
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
![Page 19: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/19.jpg)
PATTERN CREAZIONALI
![Page 20: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/20.jpg)
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@.
![Page 21: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/21.jpg)
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.
![Page 22: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/22.jpg)
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.
![Page 23: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/23.jpg)
PATTERN STRUTTURALI
![Page 24: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/24.jpg)
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.
![Page 25: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/25.jpg)
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à")
![Page 26: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/26.jpg)
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@")
![Page 27: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/27.jpg)
PATTERN COMPORTAMENTALI
![Page 28: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/28.jpg)
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
![Page 29: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/29.jpg)
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.
![Page 30: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/30.jpg)
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
![Page 31: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/31.jpg)
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.
![Page 32: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/32.jpg)
Design Pa>erns : GoF • The Sacred Elements of the Faith
![Page 33: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/33.jpg)
![Page 34: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/34.jpg)
Design Pa>erns everywhere
![Page 35: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/35.jpg)
PATTERN CREAZIONALI
![Page 36: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/36.jpg)
![Page 37: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/37.jpg)
SINGLETON Gof pag. 117
![Page 38: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/38.jpg)
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.
![Page 39: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/39.jpg)
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.
![Page 40: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/40.jpg)
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
![Page 41: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/41.jpg)
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.
![Page 42: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/42.jpg)
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)
![Page 43: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/43.jpg)
Singleton
Stru*ura
![Page 44: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/44.jpg)
Singleton
Schema del modello • Si presenta di seguito una delle implementazioni più semplici
del Singleton:
![Page 45: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/45.jpg)
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.
![Page 46: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/46.jpg)
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.
![Page 47: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/47.jpg)
Singleton
Implementazione
![Page 48: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/48.jpg)
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.
![Page 49: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/49.jpg)
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.
![Page 50: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/50.jpg)
Singleton
Sincronizzazione esplicita
![Page 51: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/51.jpg)
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.
![Page 52: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/52.jpg)
Singleton
Sincronizzazione implicita
![Page 53: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/53.jpg)
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
![Page 54: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/54.jpg)
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
![Page 55: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/55.jpg)
ENTERPRISE PATTERN
![Page 56: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/56.jpg)
Enterprise Pa>erns • Pa>erns of Enterprise Applica@on Architecture • Core J2EE Pa>erns • Integra@on Pa>erns
![Page 57: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/57.jpg)
Enterprise Pa>erns > books
![Page 58: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/58.jpg)
![Page 59: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/59.jpg)
Core J2EE Pa>erns • Presenta@on Tier • Business Tier • Integra@on Tier
![Page 60: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/60.jpg)
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
![Page 61: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/61.jpg)
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
![Page 62: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/62.jpg)
Core J2EE Pa>erns • Integra@on Tier
– Data Access Object (DAO) – Domain Store – Service Ac@vator – Web Service Broker
![Page 63: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/63.jpg)
Presenta@on Tier Pa>ern – Applica@on Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercep@ng Filter – Service To Worker – View Helper
![Page 64: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/64.jpg)
FRONT CONTROLLER PoEAA -‐ pag. 117
![Page 65: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/65.jpg)
FRONT CONTROLLER
![Page 66: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/66.jpg)
FRONT CONTROLLER !
![Page 67: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/67.jpg)
Front Controller
Descrizione • Consente di ges@re il mapping logico delle risorse
![Page 68: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/68.jpg)
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.
![Page 69: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/69.jpg)
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.
![Page 70: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/70.jpg)
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
![Page 71: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/71.jpg)
Front Controller
![Page 72: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/72.jpg)
Front Controller
![Page 73: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/73.jpg)
Front Controller
![Page 74: Design patterns - parte 1](https://reader034.vdocuments.site/reader034/viewer/2022052301/554c5432b4c905452e8b49c9/html5/thumbnails/74.jpg)
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