UGIdotNET Home UGIdotNET Home
UGIdotNET Blogs UGIdotNET Blogs
UGIdotNET Forum UGIdotNET Forum
MSDN Architetti MSDN Architetti
Visualizza Modifiche Visualizza Modifiche
Modifica Modifica
Stampa Stampa
Modifiche Recenti Modifiche Recenti
Sottoscrizioni Sottoscrizioni
Ufficio Oggetti Smarriti Ufficio Oggetti Smarriti
Cerca Riferimenti Cerca Riferimenti
Rinomina Rinomina
Cerca

Versioni

04/10/2007 16.43.02
-213.140.16.182
04/10/2007 16.41.40
-213.140.16.182
20/12/2006 15.38.55
-83.103.36.228
22/02/2006 19.39.00
StefanoUliana-81.174.11.226
22/02/2006 19.36.41
ulis@libero.it-81.174.11.226
Elenco completo versioni Elenco completo versioni
Pattern Observer
.
Summary Un design pattern che definisce una relazione uno a molti tra oggetti in modo tale che quando un oggetto cambia stato tutti gli oggetti da lui dipendenti vengono automaticamente notificati.

Conosciuto anche come

Publish-Subscribe, Callback, Dependents, Observer.

Intento

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

Motivazione

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

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

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

Approfondimenti

Sono 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

  • Quali caratteristiche ha un sistema che usa in modo estensivo il design pattern observer?
    • In che modo va affrontato il debug del codice di tale sistema?
  • Come può essere gestita la concorrenza quando si applica questo pattern? Considera il caso in cui un observer esegua Detach() appena prima che subject esegua un Notify().

Link

http://c2.com/cgi/wiki?ObserverPattern

VediAnche CatalogoDeiDesignPattern, DesignPattern#PatternComuni

UGIdotNETWiki

UGIdotNETWiki è 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

  • PatternObserver
© 2008 User Group Italiano UGIdotNET. Tutti i diritti riservati. Note legali