Design Pattern

IoC, DI e Unity 2.1- DomusDotNet

Pietro Libro — Wed, 01 Jun 2011 07:31:00 GMT

A maggio 2011 è stata rilasciata la versione 2.1 di Unity, il Dependency Injection Container di casa Microsoft per applicazioni Desktop e Silverlight, scaricabile via NuGet o Installer. Su DomusDotNet un articolo di una serie di due su IoC, DI e naturalmente Unity. Al solito, critiche e suggerimenti sono sempre ben accetti .

Design Pattern: Adapter Pattern

Pietro Libro — Tue, 06 Jul 2010 08:21:00 GMT

L’Adapter Pattern appartiene alla categoria “Structural Pattern”, secondo l’identificazione proposta dalla GoF. In questa categoria ricadono i patterns che usano i meccanismi di un linguaggio per facilitare la progettazione, individuando un modo semplice per stabilire la relazione tra gli oggetti. Per descrivere il contesto in cui può essere applicato il pattern in oggetto, supponiamo di avere il seguente scenario: dobbiamo sviluppare un software utilizzando librerie di terze parti di cui non abbiamo il codice sorgente. Vogliamo far “collaborare” due classi A e B appartenenti alle due librerie, ma aventi interfacce incompatibili. Per far funzionare il tutto abbiamo bisogno di costruire qualcosa che serva da “adattatore”. Nel mondo reale, se abbiamo un elettrodomestico che usa una spina schuko, ma a parete abbiamo una presa da 10A, per poter utilizzare l’apparecchio dobbiamo comprare un adattore ( se non ne abbiamo uno). Un altro contesto in cui può essere utilizzato questo pattern è il seguente: supponiamo di voler creare un oggetto che contenta un metodo che possa essere invocato da un client in maniera non diretta: il metodo può essere invocato solo da uno o più metodi pubblici esposti verso l’esterno che possono avere firme differenti dal metodo “core” nascosto al resto del mondo. In questo modo la classe può subire modifiche mantenendo le retrocompatibilità, oppure implementare un unico punto funzionalità a cui il client accede. Non bisogna confondere l’Adapter Pattern con il Bridge Pattern. Gli attori che entrano in gioco nell’Adapter Pattern sono: - Target, l’interfaccia che gli oggetti (client) devono utilizzare - Client, oggetti che utilizzano altri oggetti che implementano l’interfaccia Target - Adaptee, interfaccia che vogliamo adattare - Adattatore (Adapter), adatta l’interfaccia Adaptee (vecchia) a quella Target (Nuova) Secondo che l’adapter abbia al suo interno un riferimento ad un Adaptee o che utilizzi l’ereditarietà multiplia, abbiamo due modi diversi di risolvere il problema: Object Adapters: usa una tecnica composizionale per adattare un’interfaccia ad un’altra. L’Adapter eredita l’interfaccia target che il client si aspetta di utilizzare, gestendo un riferimento all’istanza dell’Adaptee. Quando il client invoca un metodo dell’Adapter, la richiesta è tradotta in una specifica richiesta per l’Adaptee. Class Adapter: utilizza l’eredità multipla per raggiungere lo scopo. Come per Object Adapters, la classe Adapter eredita l’interfaccia Target (quella che si aspetta il client), ma anche quella dell’Adaptee. In questo caso, una richiesta ad un metodo Target viene semplicemente “girata” allo specifico metodo descritto dall’interfaccia dell’Adaptee. Per aggiungere del colore al post, di seguito il diagramma delle classi (creato con VS2010) secondo la soluzione Object Adapters : Nel diagramma sono presenti due Package (namespace C#) che cercano di evidenziare lo scenario descritto precedentemente dove all’interno di QueueObjects, ICustomQueue e CustomAdapter possono essere visibili da tutti (Public) mentre ListAdapter è internal, quindi visibile solo da i file presenti nello stesso assembly. Se immaginiamo quindi i due namespace come assembly, il gioco è fatto. In questo esempio, il client pensa di lavorare con una coda (Queue), ma in realtà lavora con un oggetto (tramite il CustomAdapter) che richiama i metodi di una lista presente nell’Adaptee (listAdaptee) e che si comporta da coda FIFO. Il codice dell’esempio è il seguente: ICustomQueue 1: public interface ICustomQueue 2: { 3: Object Dequeue(); 4: 5: void Enqueue(Object item); 6: 7: void Purge(); 8: 9: } CustomAdapter 1: public class CustomAdapter : ICustomQueue 2: { 3: private ListAdaptee _listAdaptee = null; 4: 5: 6: public virtual Object Dequeue() 7: { 8: return _listAdaptee.Get(); 9: } 10: 11: public virtual void Enqueue(Object item) 12: { 13: _listAdaptee.Add(item); 14: } 15: 16: public virtual void Purge() 17: { 18: _listAdaptee.Clear(); 19: } 20: 21: public CustomAdapter() 22: { 23: _listAdaptee = new ListAdaptee(); 24: } 25: } ListAdaptee. Piccola osservazione: in un caso reale si potrebbe usare direttamente un oggetto di tipo List, ma nell’esempio ho cercato di enfatizzare il concetto di “Adattamento” che non può sempre essere risolto in modo banale 1: internal class ListAdaptee 2: { 3: private List<Object> _objectsList = null; 4: 5: public virtual void Add(Object item) 6: { 7: _objectsList.Add(item); 8: } 9: 10: public virtual Object Get() 11: { 12: Object item = null; 13: 14: if (_objectsList.Count > 0) 15: { 16: item = _objectsList.Take(1).FirstOrDefault(); 17: _objectsList.Remove(item); 18: } 19: 20: return item; 21: } 22: 23: public virtual void Clear() 24: { 25: _objectsList.Clear(); 26: } 27: 28: public ListAdaptee() 29: { 30: _objectsList = new List<object>(3); 31: } 32: } Client 1: public class Client 2: { 3: ICustomQueue _customQueue = null; 4: 5: public virtual ICustomQueue ICustomQueue 6: { 7: get 8: { 9: return _customQueue; 10: } 11: } 12: 13: public Client() 14: { 15: _customQueue = new CustomAdapter(); 16: } 17: 18: public virtual void Test() 19: { 20: _customQueue.Enqueue("1"); 21: _customQueue.Enqueue("2"); 22: _customQueue.Enqueue("3"); 23: _customQueue.Enqueue("4"); 24: _customQueue.Enqueue("5"); 25: 26: Console.WriteLine(_customQueue.Dequeue().ToString()); 27: Console.WriteLine(_customQueue.Dequeue().ToString()); 28: Console.WriteLine(_customQueue.Dequeue().ToString()); 29: Console.WriteLine(_customQueue.Dequeue().ToString()); 30: Console.WriteLine(_customQueue.Dequeue().ToString()); 31: } 32: } Possiamo testare il codice con una semplice applicazione console 1: class Program 2: { 3: static void Main(string[] args) 4: { 5: ClientObjects.Client client = new ClientObjects.Client(); 6: client.Test(); 7: 8: Console.Read(); 9: } 10: } Ottenendo:

Design Pattern: Proxy Pattern

Pietro Libro — Fri, 25 Jun 2010 10:06:00 GMT

Con questo post, vorrei iniziare un nuovo “filone” del mio blog a riguardo dei Design Pattern. Penso che descrivere e contestualmente tirar giù qualche riga di codice d’esempio, possa essere un ottimo esercizio (personale) per meglio comprendere un problema (nello specifico un pattern), o per creare un momento di riflessione/discussione sull’argomento. Una definizione di Pattern, che a mio parere descrive bene cosa esso sia è: “Un Pattern è una descrizione di una soluzione, riusabile per un problema ben conosciuto”. L’idea è quella di descrivere la soluzione in un linguaggio comprensibile (come il linguaggio naturale) prima di tradurla in linee di codice. Per Design Pattern, possiamo affidarci a Wikipedia: “A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.” Dopo questa breve (brevissima) introduzione, penso che sia abbastanza chiaro il vantaggio di utilizzare uno o più Design Pattern (quelli necessari) durante il Design e lo sviluppo delle nostre applicazioni. In questo primo post vediamo il “Proxy Pattern”. Dagli autori (GoF, gang of four) del libro “Design Patterns: Elements of Reusable Object-Oriented Software”, il Proxy Pattern è descritto come l’intento di fornire un segnaposto o surrogato di un altro oggetto di cui si vuole controllare l’accesso. Del resto, una classe proxy, nella sua forma più generale è una classe che si comporta come “interfaccia” per qualcos’altro. Di questo pattern ne esistono diverse varianti, tra cui: - Virtual Proxy (o Lazy Instantiation Pattern) - Protection Proxy (o Security Proxy) Virtual Proxy (Lazy Instantiation Pattern) Un’applicazione, normalmente, è un insieme di componenti. Questi non necessariamente devono essere tutti caricati quando l’applicazione si avvia, soprattutto nel caso in cui alcuni di questi richiedano un certo numero di risorse (come ad esempio una collezione di immagini ad alta risoluzione, un database ad oggetti, un grafo di oggetti molto denso ecc …). In questi casi si può ipotizzare di eseguire il load di questi componenti solo quando richiesti dal client (on demand). In casi come questi possiamo utilizzare il Virtual Proxy Pattern che esegue il defer (o Lazy Loading) del processo di creazione di oggetti (componenti) memory-intensive migliorando le performance dell’applicazione. A questo punto qualcuno potrebbe dire che in casi come questi all’avvio dell’applicazione utilizzo un thread secondario o un pool di thread per caricare il componente o gli oggetti che richiedono un uso intensivo delle risorse, ma se questi oggetti non verranno mai utilizzati dall’applicazione, perché “sprecare” risorse di sistema? Un esempio di utilizzo di questo pattern potrebbe essere il seguente: Supponiamo di avere un processo che impiega molto tempo a recuperare un’immagine ad esempio da un database remoto o tramite una richiesta web. Supponiamo anche che la visualizzazione di quest’immagine potrebbe essere richiesta solo in alcuni scenari di utilizzo della nostra applicazione. Potremmo implementare il Virtual Proxy Pattern in questo modo: Prima di tutto, aggiungiamo un’interfaccia denominata ad esempio IRemoteResource che definisce il metodo GetResource() per ottenere un’immagine dal web. 1: public interface IRemoteResource 2: { 3: Image GetResource(); 4: } Di seguito l’implementazione dell’interfaccia IRemoteResource 1: public class RealRemoteResource : IRemoteResource 2: { 3: private Image _resource = null; 4: 5: public RealRemoteResource(Guid resourceId) 6: { 7: _resource = LoadResource(resourceId); 8: } 9: 10: private Image LoadResource(Guid resourceId) 11: { 12: ////Download image from internet. 13: System.Net.WebClient wc = new System.Net.WebClient(); 14: string address = string.Format(@"http://www.esempio.com/images/{0}.png", resourceId); 15: string localFilePath = string.Format(@".\Images\image_{0}.png", resourceId); 16: wc.DownloadFile(address, localFilePath); 17: return Image.FromFile(localFilePath); 18: } 19: 20: #region IRemoteResource Members 21: 22: public Image GetResource() 23: { 24: return _resource; 25: } 26: 27: #endregion 28: } Molto semplicemente questa classe accetta nel costruttore un argomento che specifica l’ID della risorsa (immagine) che si vuole ottenere e contestualmente chiama il metodo privato LoadResource(…) per eseguire il Download del file dall’indirizzo specificato e salvare il contenuto sul file system locale. Di seguito l’implementazione della classe Proxy, che esegue il loading delle risorse quando richiesto: 1: public class ProxyRemoteResource : IRemoteResource 2: { 3: private Image _resource = null; 4: private Guid _resourceId = Guid.Empty; 5: 6: public ProxyRemoteResource(Guid resourceId) 7: { 8: _resourceId = resourceId; 9: } 10: 11: #region IRemoteResource Members 12: 13: public Image GetResource() 14: { 15: if (_resource == null) 16: { 17: _resource = new RealRemoteResource(_resourceId).GetResource(); 18: } 19: 20: return _resource; 21: } 22: 23: #endregion 24: } Un esempio di utilizzo delle classi su esposte: 1: Guid resourceId1 = Guid.Parse("559B4505-6D50-4936-8D4B-D871D00B5C1C"); 2: Guid resourceId2 = Guid.Parse("F14E2C9D-3785-4047-94C2-68361419A9E1"); 3: 4: ProxyRemoteResource proxyRemoteResource1 = new ProxyRemoteResource(resourceId1); 5: ProxyRemoteResource proxyRemoteResource2 = new ProxyRemoteResource(resourceId2); 6: 7: proxyRemoteResource1.GetResource(); //Load 8: proxyRemoteResource2.GetResource(); //Load 9: proxyRemoteResource1.GetResource(); //No loading. Already done. Possiamo notare come alla riga 7 ed 8 siano eseguite le chiamate GetResource() per le due istanze delle classi Proxy che eseguono il Download delle immagini dal Web. Nel caso presente alla riga 9, non viene eseguito nessun download essendo stato eseguito precedentemente (riga 7). In rete sono presenti numerosi esempi di questo pattern. Nel prossimo post approfondiremo e vedremo un esempio di Protection Proxy Pattern.