Versioni
| Conosciuto anche comePublish-Subscribe, Callback, Dependents, Observer. IntentoIl design pattern Observer viene in aiuto quando un oggetto (ConcreteSubject) vuole notificare il suo cambio di stato (subjectState) a un gruppo di oggetti (i ConcreteObserver) a lui dipendenti. La relazione tra l'oggetto che cambia stato (il subject o publisher che dir si voglia) e gli oggetti che vengono notificati (gli observer detti anche subscriber) viene stabilita in modo dinamico ossia a run-time. Per questo, questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Comportamentali . Diagramma in UML
Un'altro diagramma equivalente qui . MotivazioneUna conseguenza abbastanza comune nel comporre un sistema software con classi distinte che cooperano tra di loro è la necessità di coordinare, mantenere sincronizzato, lo stato degli oggetti che cooperano tra di loro. Questa necessità può essere assolta con il design pattern Observer che a differenza di altre soluzioni non provoca un forte accoppiamento tra le classi subject e observer ossia non provoca una RelazioneDiDipendenza tra le classi subject e l'observer. Esempi d'uso in .NETIl design pattern observer viene usato in lungo ed in largo in .NET. Viene usato negli eventi dei controlli Windows e quelli Web: i controlli sono il subject e le pagine web e i form windows sono gli observer mentre le procedure di gestione evento come Button1_Click corrispondono al metodo Update() del observer e tutte le property del controllo corrispondono al metodo GetState(). Vene usato nella classe FileSystemWatcher che è un subject che notifica gli eventi di creazione, modifica, cambio nome e cancellazione di file e directory a cui gli observer che lo desiderano possono sottoscriversi. Observer è utilizzato anche nei Delegate che stanno alla base della implementazione degli eventi e che vengono utilizzati ad esempio anche per invocare in modo asincrono i metodi sfruttando il ThreadPool del CLR. Note sulla implementazione in .NETUn esempio di implementazione del design pattern Observer in .NET: http://msdn.microsoft.com/msdnmag/issues/05/07/DesignPatterns/default.aspx?fig=true#fig1 Un esempio di implementazione del design pattern Observer in .NET con i delegate: http://msdn.microsoft.com/msdnmag/issues/05/07/DesignPatterns/default.aspx?fig=true#fig2 Del codice .NET di esempio è disponibile qui . ApprofondimentiSono comuni i casi in cui un unico subject comunica i suoi cambi di stato a diversi observer e anche casi in cui in unico observer osserva il cambio di stato di più subject. Non è previsto che gli observer possano sollevare eccezioni durante l'esecuzione del metodo di Update() perchè il subject non deve avere conoscienza di come gestirle, alpiù può essere predisposto per ignorarle. Qualora il metodo di Update() preveda dei valori di ritorno ad uso del subject è utile considerare i casi in cui ci può essere uno e uno solo observer (questo è un caso particolare), i casi in cui ce ne possono essere più d'uno e i casi in cui potrebbe non essercene nessuno (questi ultimi due casi sono quelli abituali). In alcuni casi la notifica del cambiamento di stato del subject viene comunicato agli observer in modo asincrono ossia l'esecuzione del metodo Update() è asincrona, in questo caso i valori di ritorno sono meno utili. Quando l'observer è uno solo si usa più frequentemente il nome di callback invece che observer. Domande di approfondimento
Linkhttp://c2.com/cgi/wiki?ObserverPattern | UGIdotNETWikiUGIdotNETWiki è il WikiWiki italiano dedicato a .NET Se è la prima volta che senti parlare di Wiki, leggi il BenvenutoAiVisitatori e WikiInUnMinuto, oppure il ManualePassoPassoDelWiki. Argomenti Recenti | ||||||||||||||||||||||||||||||||||||||
| © 2008 User Group Italiano UGIdotNET. Tutti i diritti riservati. Note legali | ||||||||||||||||||||||||||||||||||||||||