Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
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 would be good if each new operation could be added separately and the node classes (Element in the thumbnail) were independent of the operations that apply to them. To have both, package related operations from each class in a separate object, called a visitor, and pass it to elements of the abstract syntax tree as its traversed. When an element "accepts" the visitor, it sends a request to the visitor that encodes the elements 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. For example, if a compiler type-checked a procedure using visitors, then it would create a TypeCheckingVisitor (ConcreteVisitor in the thumbnail) object and call the Accept operation on the abstract syntax tree with that object as an argument. Each of the nodes would implement Accept by calling back on the visitor: an assignment node calls VisitAssignment operation on a visitor, while a variable reference calls VisitVariableReference. What used to be the TypeCheck operation in class AssignmentNode (ConcreteElement in the thumbnail) is on the VisitAssignment operation on TypeCheckingVisitor. To make visitors work for more than just type-checking, we need an abstract parent class NodeVisitor (Visitor in the thumbnail) for all visitors of an abstract syntax tree. NodeVisitor must declare an operation for each node class. An application that needs to compute program metrics will define new subclasses of NodeVisitor and will no longer need to add application-specific code to the node classes. The Visitor pattern encapsulates the operations for each compilation phase in a Visitor associated with that phase. With the Visitor pattern, you define two class hierarchies: one for the elements being operated on (the Node hierarchy) and one for the visitors that define operations on the elements (the NodeVisitor hierarchy). You create a new operation by adding a new subclass in the visitors class hierarchy. As long as the grammar that the compiler accepts doesnt change (that is, we dont have to add new Node subclasses), we can add new functionality simply by defining new NodeVisitor subclasses.
This pattern has been used on the following systems: The Visitor class called ProgramNodeEnumerator in the Smalltalk-80 compiler is used primarily for algorithms that analyze source code. IRIS Inventor is a toolkit for developing 3-D graphics applications. Inventor represents a three-dimensional scene as a hierarchy of nodes, each representing either a geometric object or an attribute of one. Operations like rendering a scene or mapping an input event require traversing this hierarchy in different ways. Inventor does this using visitors called "actions." (Strauss, P.S., IRIS Inventor, a 3D graphics toolkit. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 192-200, Washington, D.C., September 1993. ACM Press.)
Composite and Interpreter patterns
Composite pattern, Interpreter pattern, Visitor pattern, behavioral patterns, Gamma patterns, encapsulation (behavior), operation (adding new), gather related operations
any system requiring dynamic behavioral assignments to objectsany system with high degree of behavioral variation
classes with different interfaces - need to perform similar operations across themneed to modify object behaviors dynamically without affecting existing objects
accumulates state - avoiding globals and operation parametersallows you to vary the behavior of a class independent of its contextchangeability and extensibility of componentslocalizes state-specific behaviorprovides hierarchies of behavioral reuse
class hierarchies become unmanageablemay compromise encapsulation
Simple implementation of the pattern - Visitor class. Visitor.javaSimple implementation of the pattern - Element class. Element.javaSimple implementation of the pattern - ConcreteVisitor2 class. ConcreteVisitor2.javaSimple implementation of the pattern - ConcreteVisitor1 class. ConcreteVisitor1.javaSimple implementation of the pattern - ConcreteElementB class. ConcreteElementB.javaSimple implementation of the pattern - ConcreteElementA class. ConcreteElementA.javaSimple implementation of the pattern. visitor.h