Design patterns - parte 1
•
18 gefällt mir•2,103 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie Design patterns - parte 1
Ähnlich wie Design patterns - parte 1 (20)
Mehr von Fabio Armani
Mehr von Fabio Armani (19)
Design patterns - parte 1
- 7. 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.
- 8. fabio.armani
- 9. 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
- 10. Overview • Design Pa>ern – Stru>ura di un pa>ern – Classificazione dei design pa>ern
- 11. 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
- 12. 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
- 13. Design Pa>erns > libri
- 14. Stru>ura di un pa>ern • Un pa>ern può avere una precisa stru>ura che lo descrive
- 15. 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
- 16. 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
- 17. 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
- 18. 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
- 20. 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@.
- 21. 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.
- 22. 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.
- 24. 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.
- 25. 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à")
- 26. 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@")
- 28. 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
- 29. 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.
- 30. 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
- 31. 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.
- 32. Design Pa>erns : GoF • The Sacred Elements of the Faith
- 37. Gof pag. 117 SINGLETON
- 38. 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.
- 39. 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.
- 40. 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
- 41. 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.
- 42. 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)
- 44. Singleton Schema del modello • Si presenta di seguito una delle implementazioni più semplici del Singleton:
- 45. 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.
- 46. 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.
- 48. 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.
- 49. 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.
- 51. 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.
- 53. 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
- 54. 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
- 56. Enterprise Pa>erns • Pa>erns of Enterprise Applica@on Architecture • Core J2EE Pa>erns • Integra@on Pa>erns
- 57. Enterprise Pa>erns > books
- 59. Core J2EE Pa>erns • Presenta@on Tier • Business Tier • Integra@on Tier
- 60. 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
- 61. 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
- 62. Core J2EE Pa>erns • Integra@on Tier – – – – Data Access Object (DAO) Domain Store Service Ac@vator Web Service Broker
- 63. Presenta@on Tier Pa>ern – Applica@on Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercep@ng Filter – Service To Worker – View Helper
- 64. PoEAA -‐ pag. 117 FRONT CONTROLLER
- 65. FRONT CONTROLLER
- 67. Front Controller Descrizione • Consente di ges@re il mapping logico delle risorse
- 68. 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.
- 69. 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.
- 70. Front Controller Use to Implement: • Logical Resource Mapping • Session Management • Audit Logging Avoid: • Physical Resource Mapping • Unhandled Mapping in Multyplexed Resource Mapping strategy • Logging of Arbitrary HTTTP Parameters • Duplicating Common Logic Across Multiple Front Controllers Avoid: • Invoking Commands Without Sufficient Authorization
- 71. Front Controller
- 72. Front Controller
- 73. Front Controller
- 74. 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