Design Patterns Applied Andrea Saltarello Software Architect – Software Architect – Managed Designs S.r.l.Managed Designs S.r.l. Andrea Saltarello Software Architect – Software Architect – Managed Designs S.r.l.Managed Designs S.r.l.

SponsorSponsor

Parliamo di… Architettura e OODArchitettura e OOD Design PatternDesign Pattern Enterprise Application designEnterprise Application design Architettura e OODArchitettura e OOD Design PatternDesign Pattern Enterprise Application designEnterprise Application design

Cosa è il Design? E la fase di progettazione di un sistema.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:La progettazione è la fase nella quale vengono presi in considerazione tutti i requisiti non funzionali (HA, scalabilità, integrabilità, …) del sistema: –lanalisi si concentra su cosa debba fare il sistema –il design si concentra su come debba farlo Dobbiamo concepire larchitettura del nostro sistema.Dobbiamo concepire larchitettura del nostro sistema. E la fase di progettazione di un sistema.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:La progettazione è la fase nella quale vengono presi in considerazione tutti i requisiti non funzionali (HA, scalabilità, integrabilità, …) del sistema: –lanalisi si concentra su cosa debba fare il sistema –il design si concentra su come debba farlo Dobbiamo concepire larchitettura del nostro sistema.Dobbiamo concepire larchitettura del nostro sistema.

Cosa è lArchitettura? Secondo la definizione ANSI/IEEE Std : Lorganizzazione basilare di un sistema, rappresentato dalle sue componenti, dalle relazioni che esistono tra di loro e con lambiente circostante, e dai principi che governano la sua progettazione e evoluzione." Secondo la definizione ANSI/IEEE Std : Lorganizzazione basilare di un sistema, rappresentato dalle sue componenti, dalle relazioni che esistono tra di loro e con lambiente circostante, e dai principi che governano la sua progettazione e evoluzione."

Object Oriented Design 101 Come procedere? Secondo lautorevole 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 dellanalisi tenendo in considerazione le possibilità offerte dallorientamento alloggetto. Un esempio? I Design Pattern! In pratica, dobbiamo rielaborare il frutto dellanalisi tenendo in considerazione le possibilità offerte dallorientamento alloggetto. Un esempio? I Design Pattern! Come procedere? Secondo lautorevole 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 dellanalisi tenendo in considerazione le possibilità offerte dallorientamento alloggetto. Un esempio? I Design Pattern! In pratica, dobbiamo rielaborare il frutto dellanalisi tenendo in considerazione le possibilità offerte dallorientamento alloggetto. 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 "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. 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? Quanti interisti ci sono in sala? 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? Quanti interisti ci sono in sala?

Serie A, stagione 2004/2005 Ecco il problema ricorrente! Ecco il problema ricorrente! Ora dobbiamo formalizzare il pattern Ecco il problema ricorrente! Ecco il problema ricorrente! Ora dobbiamo formalizzare il pattern CHIEVO-INTER2-2X INTER-PALERMO1-1X ATALANTA-INTER2-32 INTER-PARMA2-2X ROMA-INTER3-3X INTER-UDINESE3-11 MILAN-INTER0-0X LECCE-INTER2-2X INTER-LAZIO1-1X FIORENTINA-INTER1-1X INTER-BOLOGNA2-2X CAGLIARI-INTER3-3X INTER-JUVENTUS2-2X

Design Patterns defined Un pattern è contraddistinto da quattro elementi: Nome: è utile per descrivere la sua funzionalità in una o due parole.Nome: è utile per descrivere la sua funzionalità in una o due parole. Problema: descrive la classe di problemi affrontata dal patternProblema: 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 collaborazioniSoluzione: 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 patternConseguenze: sono importanti per poter valutare i costi-benefici dell'utilizzo del pattern Un pattern è contraddistinto da quattro elementi: Nome: è utile per descrivere la sua funzionalità in una o due parole.Nome: è utile per descrivere la sua funzionalità in una o due parole. Problema: descrive la classe di problemi affrontata dal patternProblema: 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 collaborazioniSoluzione: 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 patternConseguenze: sono importanti per poter valutare i costi-benefici dell'utilizzo del pattern

Utopia pattern defined Proviamo a formulare il pattern Nome: UtopiaNome: Utopia Problema: subirne sistematicamente uno in meno degli altriProblema: subirne sistematicamente uno in meno degli altri Soluzione: Difensori decenti, attenzione e alloccorrenza tanti calci nel… []Soluzione: Difensori decenti, attenzione e alloccorrenza tanti calci nel… [diagramma]diagramma Conseguenze: lapplicazione del pattern può comportare la vittoria di Scudetto/Champions League, in particolar modo in combinazione a CooperativePlayConseguenze: lapplicazione del pattern può comportare la vittoria di Scudetto/Champions League, in particolar modo in combinazione a CooperativePlay Proviamo a formulare il pattern Nome: UtopiaNome: Utopia Problema: subirne sistematicamente uno in meno degli altriProblema: subirne sistematicamente uno in meno degli altri Soluzione: Difensori decenti, attenzione e alloccorrenza tanti calci nel… []Soluzione: Difensori decenti, attenzione e alloccorrenza tanti calci nel… [diagramma]diagramma Conseguenze: lapplicazione del pattern può comportare la vittoria di Scudetto/Champions League, in particolar modo in combinazione a CooperativePlayConseguenze: lapplicazione del pattern può comportare la vittoria di Scudetto/Champions 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 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 SingletonRicordate VB6? La default instance si ottiene con Singleton Ricordate ADODB? La dipendenza dal provider si elimina con Factory MethodRicordate ADODB? La dipendenza dal provider si elimina con Factory Method I design pattern ci aiutano a risolvere problemi di tutti i giorni. Esempi: Ricordate VB6? La default instance si ottiene con SingletonRicordate VB6? La default instance si ottiene con Singleton Ricordate ADODB? La dipendenza dal provider si elimina con Factory MethodRicordate 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 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)DB-independent (tecnologia e struttura) GUI-independent (almeno Win e Web)GUI-independent (almeno Win e Web) 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)DB-independent (tecnologia e struttura) GUI-independent (almeno Win e Web)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 eterogeneeConcentrare la logica applicativa nel business layer rende agevole implementare GUI eterogenee Isolare laccesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DBIsolare laccesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DB Per soddisfare i requisiti, optiamo per una architettura a 3 livelli: Concentrare la logica applicativa nel business layer rende agevole implementare GUI eterogeneeConcentrare la logica applicativa nel business layer rende agevole implementare GUI eterogenee Isolare laccesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DBIsolare laccesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DB

OOD: Business Entities Per disaccoppiare lapplicazione dalla struttura del DB, modelliamo come classi le strutture dati gestite. Ci ispiriamo al pattern Domain Model [P of EAA, 116] Per disaccoppiare lapplicazione 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. 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 laccesso 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. 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 lindipendenza dalla struttura del DB, noi utilizzeremo come parametri istanze delle business entities 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 lindipendenza 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 lelemento corrispondente non esiste nel DB? Restituire un null non è una soluzione, perché rompe il polimorfismo. Usiamo il pattern Special Case [P of EAA, 496] Che succede se chiediamo al DAL una ricerca per codice/chiave e lelemento 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 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 linterfaccia 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 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 nellusare 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 objectIniettare mock object Utilizzare light container per configurare lapplicazioneUtilizzare light container per configurare lapplicazione 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 objectIniettare mock object Utilizzare light container per configurare lapplicazioneUtilizzare light container per configurare lapplicazione

Pattern vs. Idiomi Un pattern insiste sul paradigmaUn pattern insiste sul paradigma Un idioma insiste sulla tecnologiaUn idioma insiste sulla tecnologia Es: Observer vs. Delegate/eventi Un pattern insiste sul paradigmaUn pattern insiste sul paradigma Un idioma insiste sulla tecnologiaUn idioma insiste sulla tecnologia Es: Observer vs. Delegate/eventi

RiferimentiRiferimenti Docs: IoC:IoC: GoF P of EAA Tool: NSpring: IoC:IoC: GoF P of EAA Tool: NSpring:

LinksLinks