·Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for "static semantic" analyses like checking that all variables are defined. It will also need to generate code. It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. It would be better if each new operation could be added separately, and the ode classes were independent of the operations that apply to them.

·We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it's traversed. When an element accepts the visitor, it sends a request to the visitor that encodes the element's class. It also includes the element as an argument. The visitor will then execute the operation for that element—the operation that used to be in the class of the element.

odeclares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the elements directly through its particular interface

·ConcreteVisitor (IncomeVisitor, VacationVisitor)

oimplements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class or object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure.

·Element (Element)

odefines an Accept operation that takes a visitor as an argument.

·ConcreteElement (Employee)

oimplements an Accept operation that takes a visitor as an argument

·ObjectStructure (Employees)

ocan enumerate its elements

omay provide a high-level interface to allow the visitor to visit its elements

omay either be a Composite (pattern) or a collection such as a list or a set

This structural code demonstrates the Visitor pattern in which an object traverses an object structure and performs the same operation on each node in this structure. Different visitor objects define different operations.

namespace Xpanxion.Visitor

{

class MainApp

{

static void Main()

{

// Setup structure

ObjectStructure o = new ObjectStructure();

o.Attach(new ConcreteElementA());

o.Attach(new ConcreteElementB());

// Create visitor objects

ConcreteVisitor1 v1 = new ConcreteVisitor1();

ConcreteVisitor2 v2 = new ConcreteVisitor2();

// Structure accepting visitors

o.Accept(v1);

o.Accept(v2);

// Wait for user

Console.Read();

}

}

// "Visitor"

abstract class Visitor

{

public abstract void VisitConcreteElementA(

ConcreteElementA concreteElementA);

public abstract void VisitConcreteElementB(

ConcreteElementB concreteElementB);

}

// "ConcreteVisitor1"

class ConcreteVisitor1 : Visitor

{

public override void VisitConcreteElementA(

ConcreteElementA concreteElementA)

{

Console.WriteLine("{0} visited by {1}",

concreteElementA.GetType().Name, this.GetType().Name);

}

public override void VisitConcreteElementB(

ConcreteElementB concreteElementB)

{

Console.WriteLine("{0} visited by {1}",

concreteElementB.GetType().Name, this.GetType().Name);

}

}

// "ConcreteVisitor2"

class ConcreteVisitor2 : Visitor

{

public override void VisitConcreteElementA(

ConcreteElementA concreteElementA)

{

Console.WriteLine("{0} visited by {1}",

concreteElementA.GetType().Name, this.GetType().Name);

}

public override void VisitConcreteElementB(

ConcreteElementB concreteElementB)

{

Console.WriteLine("{0} visited by {1}",

concreteElementB.GetType().Name, this.GetType().Name);

}

}

// "Element"

abstract class Element

{

public abstract void Accept(Visitor visitor);

}

// "ConcreteElementA"

class ConcreteElementA : Element

{

public override void Accept(Visitor visitor)

{

visitor.VisitConcreteElementA(this);

}

public void OperationA()

{

}

}

// "ConcreteElementB"

class ConcreteElementB : Element

{

public override void Accept(Visitor visitor)

{

visitor.VisitConcreteElementB(this);

}

public void OperationB()

{

}

}

// "ObjectStructure"

class ObjectStructure

{

private ArrayList elements = new ArrayList();

public void Attach(Element element)

{

elements.Add(element);

}

public void Detach(Element element)

{

elements.Remove(element);

}

public void Accept(Visitor visitor)

{

foreach (Element e in elements)

{

e.Accept(visitor);

}

}

}

}

1.8Sample Code2

This real-world code demonstrates the Visitor pattern in which two objects traverse a list of Employees and performs the same operation on each Employee. The two visitor objects define different operations -- one adjusts vacation days and the other income.

1.9C# Iterators and Visitor Pattern

The iterators are coded directly into the class to be iterated. For example:

public IEnumerable<int> Visit(SomeVisitor visitor)

{

int position = 0;

for(int i = 0; i < Count; i++)

{

yield return position;

data[i].Accept(visitor);

position++;

}

}

This can then be used in a foreach construct:

foreach(int position in someObject.Visit(this))

{

// Do something with position here.

}

Where 'someObject' is the object to traverse, the class of which contains the iterator code above, and 'this' is an instance of a class derived from 'SomeVisitor.'

So as the object is traversed, the iterator first returns the position information. Here it is just a simple integer, but it could be anything, something much more complex, perhaps. Then the Accept method is called.

The idea is that you can traverse a collection where the Visitor design pattern is used without having to explicitely call the Accept method; the iterator takes care of that for you. Plus, you get additional information about the traversal that can be used as well. Care would have to be taken so that you know which comes first, the value returned from the iterator or the Accept method being called.