Design Patterns Applied

1. Design Patterns Applied Andrea Saltarello Software Architect – Managed Designs S.r.l. http://blogs.ugidotnet.org/pape

2. Sponsor

3. Parliamo di… • Architettura e OOD • Design Pattern • Enterprise Application design

4. Cosa è il Design? • 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: • l’analisi si concentra su cosa debba fare il sistema • il design si concentra su come debba farlo • Dobbiamo concepire l’architettura del nostro sistema.

5. Cosa è l’Architettura? Secondo la definizione ANSI/IEEE Std 1471-2000: “L’organizzazione basilare di un sistema, rappresentato dalle sue componenti, dalle relazioni che esistono tra di loro e con l’ambiente circostante, e dai principi che governano la sua progettazione e evoluzione."

6. Object Oriented Design 101 Come procedere? Secondo l’autorevole “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 dell’analisi tenendo in considerazione le possibilità offerte dall’orientamento all’oggetto. Un esempio? I Design Pattern! 

7. 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

8. 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.

9. 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? 

10. Serie A, stagione 2004/2005 Ecco il problema ricorrente!  Ora dobbiamo formalizzare il pattern

11. Design Patterns defined Un pattern è contraddistinto da quattro elementi: • Nome: è utile per descrivere la sua funzionalità in una o due parole. • Problema: 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 collaborazioni • Conseguenze: sono importanti per poter valutare i costi-benefici dell'utilizzo del pattern

12. “Utopia” pattern defined Proviamo a formulare il pattern • Nome: Utopia • Problema: subirne sistematicamente uno in meno degli altri • Soluzione: Difensori decenti, attenzione e all’occorrenza tanti calci nel…  [diagramma] • Conseguenze: l’applicazione del pattern può comportare la vittoria di Scudetto/Champion’s League, in particolar modo in combinazione a CooperativePlay

13. 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”

14. Design Patterns applied I design pattern ci aiutano a risolvere problemi di tutti i giorni. Esempi: • Ricordate VB6? La default instance si ottiene con Singleton • Ricordate ADODB? La dipendenza dal provider si elimina con Factory Method

15. Design Patterns applied: Singleton Problema:Ensure a class has only one instance and provide a global point of access to it.

17. 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.

19. Dice il saggio… Non dobbiamo pensare ai pattern come a dogmi, bensì come alle centurie di Nostradamus: vanno interpretati 

20. 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) • GUI-independent (almeno Win e Web)

21. 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 eterogenee • Isolare l’accesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DB

22. OOD: Business Entities Per disaccoppiare l’applicazione dalla struttura del DB, modelliamo come classi le strutture dati gestite. Ci ispiriamo al pattern Domain Model [P of EAA, 116]

23. “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.

25. OOD: il data layer Il DAL incapsula l’accesso al database, al fine di disaccoppiare la business logic dalla tecnologia di storage. Utilizziamo il pattern Table Data Gateway [P of EAA, 144]

26. “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.

27. “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 l’indipendenza dalla struttura del DB, noi utilizzeremo come parametri istanze delle business entities

29. Domain Model strikes back Che succede se chiediamo al DAL una ricerca per codice/chiave e l’elemento corrispondente non esiste nel DB? Restituire un nullnon è una soluzione, perché “rompe” il polimorfismo. Usiamo il pattern Special Case [P of EAA, 496]

30. “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

32. 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 l’interfaccia in quella del DAL/TDG.

33. 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

35. OOD: Biz Logic vs. DAL Un modo interessante per disaccoppiare le classi di business dal corrispettivo DAL consiste nell’usare il pattern Inversion of Control (IoC), ossia una applicazione del pattern Plugin [P of EAA, 499]

36. “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 object • Utilizzare light container per configurare l’applicazione

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

39. Riferimenti Docs: • IoC: http://www.martinfowler.com/articles/injection.html Pattern: • GoF http://www.dofactory.com • P of EAAhttp://www.martinfowler.com/eaaCatalog/index.html Tool: • NSpring: http://sourceforge.net/projects/nspring

40. Links http://www.ugidotnet.org http://forum.ugidotnet.org http://mobile.ugidotnet.org