The Visitor design pattern allows you to add operations to classes without changing the classes. That pretty well summarizes what the Visitor can do for you. Imagine you’ve got a great big game program and you want to tweak the functionality of certain objects in the game by adding operations (methods and functions). Rather than opening a bag of marbles to spill out in every direction when you add functionality to a class, all you need to do is to use the Visitor to add that functionality without interfering with the rest of the class. If you’ve read Chandima’s chapter and posts on the Composite pattern, you’re two jumps ahead. Typically, the Visitor is used with a Composite pattern. Likewise, Chandima’s post on the Iterator will aid in understanding the traverse process used in the Visitor. Of course you can work perfectly well with the Visitor without background in these other patterns, but you might want to peek at them for further reference and understanding as you review the Visitor.
The Visitor Design Pattern’s Formal Features
First, take a look at the Visitor’s class diagram. You will note that the implied Client holds references to two different classes within the pattern. The factory patterns (Abstract Factory, Factory, Flyweight) all have similar multiple references from the Client, and so too does the Command, Interpreter and Iterator patterns. So don’t let the multiple references from the Client throw you. Figure 1 shows the Visitor class diagram:
Figure 1:Visitor design pattern diagram
The Client reference to the Visitor interface (IVisitor in the example program) sets up implementations for concrete visitors. The concrete visitors visit the different concrete elements. At the same time, the client goes through the ObjectStructure and the ObjectStructure has multiple object references to the Element interface. The black ball at the end of the ObjectStructure reference arrow means that it has multiple references. Figure 2 isolates that relationship from the Visitor diagram.
Figure 2: Multiple object references
Getting the ObjectStructure and its references to the Element class is an important part of working successfully with the Visitor pattern.
Double-Dispatch
One of the key processes behind the Visitor’s ability to add operations to existing classes is the double-dispatch technique. Like the name implies, double-dispatch involves two receivers. A single-dispatch involves the name of the request and the type of receiver. In double-dispatch the executed operation depends on the kind of request and two receivers. In the Visitor example program, you will see that the accept method is a double dispatch operation. Within a concrete element, it is written as:
public function accept(visitor:IVisitor):void
{
visitor.visitConcreteElementA(this);
}
The this statement refers to the Concrete Element class it is contained within. In this context you can see the visitor and element receivers that make it a double-dispatch operation. The actual operation that is executed depends on the type of Visitor and Element. Using this technique allows you to consolidate the operation in the Visitor.
Bill Sanders
Recent Comments