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

03/10/2007 1.55.30
-84.221.53.107
12/07/2007 17.54.35
LucaMinudel-193.42.138.35
30/06/2006 12.44.40
-213.140.6.121
30/06/2006 12.44.05
-213.140.6.121
19/01/2006 12.15.52
LucaMinudel-193.42.138.36
Elenco completo versioni Elenco completo versioni
Pattern Visitor
.
Summary Un design pattern che rappresenta una nuova operazione da aggiungere a tutte le classi di una gerarchia di oggetti.

Conosciuto anche come

Non ha altri nomi.

Intento

Il design pattern Visitor rappresenta un' operazione che deve essere eseguita sugli elementi di una GerarchiaDiOggetti. La nuova operazione viene definita senza modificare le classi degli oggetti della gerarchia su cui opera. L'operazione che viene eseguita è determinata da 2 cose: dal tipo concreto di Visitor (ConcreteVisitor1 piuttosto che ConcreteVisitor2, ...) e dal tipo concreto del Element (ConcreteElementA pittosto che ConcreteElementB, ...).

La classe ConcreteVisitor che rappresenta l'operazione è applicata a run-time alla GerarchiaDiOggetti quindi 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 UML

Un'altro diagramma equivalente qui e qui .

Nota: il Client chiamerà il metodo Accept dell'oggetto che è la radice della gerarchia di oggetti, l'implementazione di questo metodo Accept provvederà a chiamare il metodo Accept di tutti gli oggetti referenziati dalla radice.

Motivazione

Quando una operazione deve essere applicata ad una GerarchiaDiOggetti le cui classi appartengono ad una sola GerarchiaDiClassi (ossia hanno una classe base comune) come questa:

aggiungere una operazione (es. operation4) richiede di modificare la classe base (Parent) inserendo la nuova operazione (operation4) con le parti comuni alle varie classi derivate (Child1, Child2, Child3) per poi inserire in ognuna delle classi derivate (Child1, Child2, Child3) la nuova operazione (operation4).

Quindi aggiungere una nuova operazione in questa situazione è un'operazione onerosa; nel caso in cui gli oggetti della gerarchia appartengano a diverse gerarchie di classi (ossia non abbiano una classe base comune) diventa inevitabile duplicare la logica della operazione.

Applicando il design pattern Visitor in questo modo:

per aggiungere una nuova operazione è sufficiente implementare la classe Operation4.

Un esempio simile è disponibile qui .

Il design pattern Visitor quindi

  • semplifica l'aggiunta di una nuova operazione comune alle diverse classi di una gerarchia di oggetti
  • aiuta ad evitare duplicazioni della logica di implementazione della nuova operazione
  • è indispensabile per evitare duplicazioni della logica della nuova operazione quando gli oggetti appartengono a gerarchie di classi distinte

Quando l'operazione calcola un risultato cumulativo di tutti gli oggetti della gerarchia, non può essere implementata nella singola classe ConcreteElement e quindi necessariamente deve essere delegata a una classe ConcreteVisitor.

Il design pattern Visitor quindi

  • permette di implementare operazioni cumulative su tutti gli oggetti della gerarchia

Esempi d'uso in .NET

Nessun esempio trovato.

Note sulla implementazione in .NET

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Questo design pattern può essere usato per applicare una operazione a tutti gli oggetti di una struttura definita dal PatternComposite.

Questo design pattern può essere applicatio per realizzare il PatternInterpreter.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Il design pattern Visitor pur semplificando l'aggiunta di nuove operazioni (ConcreteVisitor3) complica invece l'aggiunta di nuove classi (ConcreteElementC) che devono supportare le operazioni esistenti (ad esempio perché i loro oggetti entrano a far parte della gerarchia di oggetti che viene visitata). Quindi il design pattern Visitor è utile quando c'è una gerarchia di classi consolidata ed invece si vuole supportare l'evoluzione con nuove operazioni.

Se la gerarchia di classi cambia frequentemente è meglio considerare alternative diverse.

Domande di approfondimento

  • Quando la gerarchia di classi cambia frequentemente e pure le operazioni vengono aggiunte frequentemente, che soluzione si può adottare?

Link

VediAnche CatalogoDeiDesignPattern

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

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