Leslie Sanford - Professional Profile

Combining Visitor, Observer, and Iterator

Leslie Sanford25-Dec-05 21:29

25-Dec-05 21:29

I've been using the Visitor, Observer, and Iterator design patterns together recently with some satisfying results. I'll go through step by step how I'm combining these three patterns.

First, we have various types of classes that implement an interface. These are the classes that accepts a visitor:

public interface IMessage
{
    void Accept(IMessageVisitor);
}

public class MessageA : IMessage
{
    public void Accept(IMessageVisitor visitor)
    {
        visitor.Visit(this);
    }
}

public class MessageA : IMessage
{
    public void Accept(IMessageVisitor visitor)
    {
        visitor.Visit(this);
    }
}

This assumes the existence of an IMessageVisitor interface, so let's declare it next:

public interface IMessageVisitor
{
    void Visit(MessageA message);

    void Visit(MessageB message);
}

The basic interfaces and classes are in place to implement the Visitor design pattern. Now for combining Visitor with Observer. We will create a MessageDispatcher class that implements the IMessageVisitor interface. It will provide functionality for raising events for each of the message classes it visits:

public class MessageDispatcher : IMessageVisitor
{
    public event EventHandler MessageAOccurred;

    public event EventHandler MessageBOccurred;

    public void Visit(MessageA message)
    {
        OnMessageAOccurred();
    }

    public void Visit(MessageB message)
    {
        OnMessageBOccurred();
    }

    protected virtual void OnMessageAOccurred()
    {
        EventHandler handler = MessageAOccurred;

        if(handler != null)
        {
            handler(this, EventArgs.Empty);
        }
    }

    protected virtual void OnMessageBOccurred()
    {
        EventHandler handler = MessageBOccurred;

        if(handler != null)
        {
            handler(this, EventArgs.Empty);
        }
    }
}

The purpose of the MessageDispatch class is simple; it raises events in response to visiting message objects.

The beauty of this class is that it can be reused in many different contexts. In fact, it may turn out that this is the only visitor class we need. Instead of creating many implementations of the IMessageVisitor interface, we can use this class instead and register with the events to be notified when the visitor visits a message type we are interested in. I'll build on this idea in another post when I explore flow-based programming.

Before I show the MessageDispatch class in action, let's now combine Visitor/Observer with Iterator. I'll use C# v2.0 iterators.

Say we have a class that has a collection of IMessage objects. We'll give it an iterator for iterating over the collection, returning the index of each object in the collection, and visiting each object in the collection:

public class MessageCollection
{
    private List<IMessage> messages = new List<IMessage>();

    // Other class declarations, methods, properties, etc...

    public IEnumerable<int> Iterator(IMessageVisitor visitor)
    {
        int index = 0;

        foreach(IMessage message in messages)
        {
            yield return index;

            message.Accept(visitor);

            index++;
        }
    }
}

Here, all we're doing is returning the collection index of each message before visiting the message. It isn't very impressive, but this is a very generic and simple example. In other situations, what your iterator returns can be just about anything, some sort of on the fly calculation, or whatever. Anything that is relevant to the traversal. And you can create several interators for your class that return different values and have different traversal strategies.

The position of the yield return statement is important and requires some thought. When the yield return is executed, the iterator returns. Viewed from the outside, this return causes the MoveNext call to complete. The rest of the code that comes after the yield return is not executed until MoveNext is called again. When used with Visitor, this is important to consider.

If you need to use the value stored in the Current property at the conclusion of a MoveNext before you visit the current object, it's important to put the yield return before the object is visited; otherwise, you may want to visit the object first.

C# Iterators are a little hard to reason about because of the jump that can happen in the middle of the iterator's code. In fact, you can have several yield returns throughout the iterator. It becomes tricky, and one is reminded of gotos, but at least so far, I'm finding iterators to be very powerful.

Now let's look at all of this in action:

public class Program
{
    private MessageCollection messages = new MessageCollection();

    private MessageDispatcher dispatcher = new MessageDispatcher();

    public Program()
    {
        dispatcher.MessageAOccurred += EventHandler(HandleMessageA);
    }

    // Other class declarations, methods, properties, etc...

    private void HandleMessageA(object sender, EventArgs e)
    {
        // Do something here.
    }

    public void ProcessMessages()
    {
        foreach(int index in messages.Iterator(dispatcher))
        {
            // Do something with index here.
        }
    }
}

This admittedly doesn't look impressive. But one advantage that's apparent even from this simple example is that our Program class doesn't have to implement the IMessageVisitor class to visit the messages. The MessageDispatcher does all of the work.

Using events in this way may seem like overkill, and if it ended with our Program class, I would agree. The real power comes in when more than one class responds to the events generated by the Visitor/Observer class. You can design classes to respond to the events raised by the Visitor/Observer class that has no knowledge of the mechanics going on behind the scenes. All they are interested in is doing something interesting with the objects being visited.

To give a more concrete example, I'm using the above approach with my MIDI toolkit. I've rewritten the playback engine to use Visitor/Observer/Iterator. Various compenents are connected to my Visitor/Observer class to process and react to MIDI events. For example, I have a clock class that responds to tempo events raised by the Visitor/Observer by changing its tempo. Also, the iterators are driven by the ticks the clock generates. It's all working well so far and has made my code more expressive.

Well, that's about it. I may return to this idea and use the above as the basis for an article at some point. That's for your time.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Leslie Sanford - Professional Profile

Summary

Reputation

Privileges