Visitor.. What's in a visit anyways...

Recently I was reading Judith Bishop's C# 3.0 Design Patterns. The book has been a good read so far.The Visitor pattern implementation in the book however is implemented "classically" wherein each element of the structure being iterated over has an Accept operation which accepts an instance of a Visitor type. When the client invokes the operation on the Visitor which is supposed to kick start the visiting,the Visitor iterates over each element of the structure in some way and invokes the Accept operation passing in itself as a reference. The element in turn invokes the Visit operation on the Visitor (passing in itself) which in turn accepts an element instance and works with it(double dispatch). But my gut tells me something seems out of place here given that the book's intent is to implement the classic GOF patterns using C# 3.0 features. To put things into perspective, I created a small generic linked list implementation based on the classic Visitor pattern

public interface INode<T>
{
T Data { get; }
INode<T> Next { get; set; }
void Accept(IVisitor<T> visitor);
}
public class Node<T> : INode<T>
{
public Node(T t)
{
Data = t;
}
public Node(T t,Node<T> next)
{
Data = t;
Next = next;
}
#region INode<T> Members
public T Data { get; private set; }
public INode<T> Next
{
get; set;
}
public void Accept(IVisitor<T> visitor)
{
visitor.Visit(this);
}
#endregion
public override string ToString()
{
return Data.ToString();
}
}
public class LinkedList<T> : IEnumerable<INode<T>>
{
private INode<T> _head;
public INode<T> Head
{
get
{
return _head;
}
}
public void Add(T data)
{
if (_head == null)
{
_head = new Node<T>(data);
}
else
{
INode<T> current = _head;
while (current.Next != null)
{
current = current.Next;
}
current.Next = new Node<T>(data);
}
}
public LinkedList(params T[] elements)
{
foreach (var ele in elements)
{
Add(ele);
}
}
#region IEnumerable<INode<T>> Members
public IEnumerator<INode<T>> GetEnumerator()
{
INode<T> current = _head;
while (current != null)
{
yield return current;
current = current.Next;
}
}
#endregion
#region IEnumerable Members
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
#endregion
}
public interface IVisitor<T>
{
void Visit(INode<T> node);
void Visit(IEnumerable<INode<T>> nodes);
}
public class ConsoleVisitor<T> : IVisitor<T>
{
#region IVisitor<T> Members
public void Visit(INode<T> node)
{
Console.WriteLine(node);
}
public void Visit(IEnumerable<INode<T>> nodes)
{
foreach (var node in nodes)
{
node.Accept(this);
}
}
#endregion
}
public class DebugVisitor<T> : IVisitor<T>
{
#region IVisitor<T> Members
public void Visit(INode<T> node)
{
Debug.WriteLine(node);
}
public void Visit(IEnumerable<INode<T>> nodes)
{
foreach (var node in nodes)
{
node.Accept(this);
}
}
#endregion
}
public class Program
{
static void Main(string[] args)
{
LinkedList<int> list = new LinkedList<int>(1, 2, 3, 4, 5 );
ConsoleVisitor<int> consoleVisitor = new ConsoleVisitor<int>();
DebugVisitor<int> debugVisitor = new DebugVisitor<int>();
consoleVisitor.Visit(list);
debugVisitor.Visit(list);
}
}

I see a number of drawbacks with this approach:

No creative use of C# 3.0 features
The Node<T> needs to know about the IVisitor interface(interface coupling).
If the LinkedList<T> was written by a 3rd party vendor, there would be no way to "pass in" a Visitor implementation
Double dispatch can hurt performance

The following implementation uses C# 3.0 features

public interface INode<T>
{
T Data { get; }
INode<T> Next { get; set; }
}
public class Node<T> : INode<T>
{
public Node(T t)
{
Data = t;
}
public Node(T t,Node<T> next)
{
Data = t;
Next = next;
}
#region INode<T> Members
public T Data { get; private set; }
public INode<T> Next
{
get; set;
}
#endregion
public override string ToString()
{
return Data.ToString();
}
}
public class LinkedList<T> : IEnumerable<T>
{
private INode<T> _head;
public INode<T> Head
{
get
{
return _head;
}
}
public void Add(T data)
{
if (_head == null)
{
_head = new Node<T>(data);
}
else
{
INode<T> current = _head;
while (current.Next != null)
{
current = current.Next;
}
current.Next = new Node<T>(data);
}
}
public LinkedList(params T[] elements)
{
foreach (var ele in elements)
{
Add(ele);
}
}
#region IEnumerable<T> Members
public IEnumerator<T> GetEnumerator()
{
INode<T> current = _head;
while (current != null)
{
yield return current.Data;
current = current.Next;
}
}
#endregion
#region IEnumerable Members
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
#endregion
}
public static class Extensions
{
public static void ForEach<T>(this IEnumerable<T> enumerable,Action<T> action)
{
foreach (var item in enumerable)
{
action(item);
}
}
}
public class Program
{
static void Main(string[] args)
{
LinkedList<int> list = new LinkedList<int>(1, 2, 3, 4, 5 );
list.ForEach( e => Console.WriteLine(e));
list.ForEach(e => Debug.WriteLine(e));
}
}

The structure being iterated over has no knowledge of a Visitor
The iteration logic is encapsulated away into the ForEach extension method which can be reused for iterating over any IEnumerable<T>
The ForEach extension method accepts an Action<T> which represents the Visitor.
The client is free to pass in any lambda representing the visiting logic; it could very well request an Action<T>from some factory(not shown).
No double dispatch
No proliferation of Visitor class hierarchies.Less code, more readabiliy and ease of maintenance

I prefer this mechanism much more over the interface based approach.With the functional programming features that C# provides, I need a compelling reason to use interfaces for tasks such as this.

Posted on Wednesday, November 12, 2008 10:48 PM Design Patterns , C# | Back to top

Comments on this post: Visitor.. What's in a visit anyways...

# re: Visitor.. What's in a visit anyways...

Nice post. I have a slightly-off-topic comment.

I have similar extention methods in my code: I use "ForEachElement", which pretty much matches your "ForEach" exactly, and I have a "ForEach", which is the same thing except that it returns IEnumberable<T> for "chaining" capability. My comment is that with all of the additions in .Net 3.5, why do we have to write these extensions just to perform an action on an element of an enumberable collection. I keep reading the documentation and trying to find the missing framework classes/methods/etc - because it just feels like this should be in the framework, already, and I just did not find it.

Left by joe on Nov 14, 2008 3:51 AM

Hi Joe,
I totally agree with your comment.My take is that since Action<T> was introduced in .NET 2.0, the framework team also introduced a static ForEach on Array
and on List<T> for performing actions using delegates at the time, since there was no notion of extension methods then.
If Extensions methods had been introduced in .NET 2.0, it would've made a lot of sense to have a ForEach on IEnumerable<T>.
Now, it would get a little ugly if the BCL team decides to include a ForEach on IEnumerable<T> going forward, we would then have an overloaded
ForEach on Array and List<T> and they would in essense be doing the same thing.
The situation get trickier particularly for List<T> since ForEach is defined as in instance method on List<T> which means that one would have to be careful and
understand the way overload resolution works for instance vs extension methods.Just my 2 cents....

Left by Abhijeet P on Nov 15, 2008 5:36 PM

Hey, that was interesting,
I check your code carefully it works absoultely fine and I love your article writing skill

Anyway, thanks for the post

Left by web development company on Aug 19, 2009 12:05 PM

Thanks. Glad you liked it.

Left by Abhijeet on Aug 23, 2009 4:07 PM