In essence, the visitor allows adding new virtual functions to a family of classes, without modifying the classes. Instead, a visitor class is created that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

Contents

The Visitor [1] design pattern is one of the twenty-three well-known GoF design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

It should be possible to define a new operation for (some) classes of an object structure without changing the classes.

When new operations are needed frequently and the object structure consists of many unrelated classes, it's inflexible to add new subclasses each time a new operation is required because "[..] distributing all these operations across the various node classes leads to a system that's hard to understand, maintain, and change." [1]

What solution does the Visitor design pattern describe?

Define a separate (visitor) object that implements an operation to be performed on elements of an object structure.

Clients traverse the object structure and call a dispatching operation accept(visitor) on an element — that "dispatches" (delegates) the request to the "accepted visitor object". The visitor object then performs the operation on the element ("visits the element").

This makes it possible to create new operations independently from the classes of an object structure by adding new visitor objects.

Consider the design of a 2D computer-aided design (CAD) system. At its core there are several types to represent basic geometric shapes like circles, lines, and arcs. The entities are ordered into layers, and at the top of the type hierarchy is the drawing, which is simply a list of layers, plus some added properties.

A fundamental operation on this type hierarchy is saving a drawing to the system's native file format. At first glance it may seem acceptable to add local save methods to all types in the hierarchy. But it is also useful to be able to save drawings to other file formats. Adding ever more methods for saving into many different file formats soon clutters the relatively pure original geometric data structure.

A naive way to solve this would be to maintain separate functions for each file format. Such a save function would take a drawing as input, traverse it, and encode into that specific file format. As this is done for each added different format, duplication between the functions accumulates. For example, saving a circle shape in a raster format requires very similar code no matter what specific raster form is used, and is different from other primitive shapes. The case for other primitive shapes like lines and polygons is similar. Thus, the code becomes a large outer loop traversing through the objects, with a large decision tree inside the loop querying the type of the object. Another problem with this approach is that it is very easy to miss a shape in one or more savers, or a new primitive shape is introduced, but the save routine is implemented only for one file type and not others, leading to code extension and maintenance problems.

Instead, the Visitor pattern can be applied. It encodes a logical operation on the whole hierarchy into one class containing one method per type. In the CAD example, each save function would be implemented as a separate Visitor subclass. This would remove all duplication of type checks and traversal steps. It would also make the compiler complain if a shape is omitted.

Another motive is to reuse iteration code. For example, iterating over a directory structure could be implemented with a visitor pattern. This would allow creating file searches, file backups, directory removal, etc., by implementing a visitor for each function while reusing the iteration code.

A sample UML class and sequence diagram for the Visitor design pattern. [4]

In the above UMLclass diagram, the ElementA class doesn't implement a new operation directly. Instead, ElementA implements a dispatching operationaccept(visitor) that "dispatches" (delegates) a request to the "accepted visitor object" (visitor.visitElementA(this)). The Visitor1 class implements the operation (visitElementA(e:Element)).ElementB then implements accept(visitor) by dispatching to visitor.visitElementB(this). The Visitor1 class implements the operation (visitElementB(e:Element)).

The UMLsequence diagram shows the run-time interactions: The Client object traverses the elements of an object structure (ElementA,ElementB) and calls accept(visitor) on each element.
First, the Client calls accept(visitor) on ElementA, which calls visitElementA(this) on the accepted visitor object. The element itself (this) is passed to the visitor so that it can "visit" ElementA (call operationA()).
Thereafter, the Client calls accept(visitor) on ElementB, which calls visitElementB(this) on the visitor that "visits" ElementB (calls operationB()).

The visitor declares a visit method, which takes the element as an argument, for each class of element. Concrete visitors are derived from the visitor class and implement these visit methods, each of which implements part of the algorithm operating on the object structure. The state of the algorithm is maintained locally by the concrete visitor class.

The element declares an accept method to accept a visitor, taking the visitor as an argument. Concrete elements, derived from the element class, implement the accept method. In its simplest form, this is no more than a call to the visitor’s visit method. Composite elements, which maintain a list of child objects, typically iterate over these, calling each child’s accept method.

The client creates the object structure, directly or indirectly, and instantiates the concrete visitors. When an operation is to be performed which is implemented using the Visitor pattern, it calls the accept method of the top-level element(s).

When the accept method is called in the program, its implementation is chosen based on both the dynamic type of the element and the static type of the visitor. When the associated visit method is called, its implementation is chosen based on both the dynamic type of the visitor and the static type of the element, as known from within the implementation of the accept method, which is the same as the dynamic type of the element. (As a bonus, if the visitor can't handle an argument of the given element's type, then the compiler will catch the error.)

Thus, the implementation of the visit method is chosen based on both the dynamic type of the element and the dynamic type of the visitor. This effectively implements double dispatch. For languages whose object systems support multiple dispatch, not only single dispatch, such as Common Lisp or C# via the Dynamic Language Runtime (DLR), implementation of the visitor pattern is greatly simplified (a.k.a. Dynamic Visitor) by allowing use of simple function overloading to cover all the cases being visited. A dynamic visitor, provided it operates on public data only, conforms to the open/closed principle (since it does not modify extant structures) and to the single responsibility principle (since it implements the Visitor pattern in a separate component).

In this way, one algorithm can be written to traverse a graph of elements, and many different kinds of operations can be performed during that traversal by supplying different kinds of visitors to interact with the elements based on the dynamic types of both the elements and the visitors.

This example shows how to print a tree representing a numeric expression involving literals and their addition. The same example is presented using both classic and Dynamic Language Runtime implementations.

In this case, it is the object's responsibility to know how to print itself on a stream. The visitor here is then the object, not the stream.

"There's no syntax for creating a class. Classes are created by sending messages to other classes."WriteStreamsubclass:#ExpressionPrinterinstanceVariableNames:''classVariableNames:''package:'Wikipedia'.ExpressionPrinter>>write:anObject"Delegates the action to the object. The object doesn't need to be of any special class; it only needs to be able to understand the message #putOn:"anObjectputOn:self.^anObject.Objectsubclass:#ExpressioninstanceVariableNames:''classVariableNames:''package:'Wikipedia'.Expressionsubclass:#LiteralinstanceVariableNames:'value'classVariableNames:''package:'Wikipedia'.Literalclass>>with:aValue"Class method for building an instance of the Literal class"^selfnewvalue:aValue;yourself.Literal>>value:aValue"Setter for value"value:=aValue.Literal>>putOn:aStream"A Literal object knows how to print itself"aStreamnextPutAll:valueasString.Expressionsubclass:#AdditioninstanceVariableNames:'left right'classVariableNames:''package:'Wikipedia'.Additionclass>>left:aright:b"Class method for building an instance of the Addition class"^selfnewleft:a;right:b;yourself.Addition>>left:anExpression"Setter for left"left:=anExpression.Addition>>right:anExpression"Setter for right"right:=anExpression.Addition>>putOn:aStream"An Addition object knows how to print itself"aStreamnextPut:$(.leftputOn:aStream.aStreamnextPut:$+.rightputOn:aStream.aStreamnextPut:$).Objectsubclass:#PrograminstanceVariableNames:''classVariableNames:''package:'Wikipedia'.Program>>main|expressionstream|expression:=Additionleft: (Additionleft: (Literalwith:1)
right: (Literalwith:2))
right: (Literalwith:3).stream:=ExpressionPrinteron: (Stringnew:100).streamwrite:expression.Transcriptshow:streamcontents.Transcriptflush.

#include<iostream>#include<vector>classAbstractDispatcher;// Forward declare AbstractDispatcherclassFile{// Parent class for the elements (ArchivedFile, SplitFile and ExtractedFile)public:// This function accepts an object of any class derived from AbstractDispatcher and must be implemented in all derived classesvirtualvoidaccept(AbstractDispatcher&dispatcher)=0;};// Forward declare specific elements (files) to be dispatchedclassArchivedFile;classSplitFile;classExtractedFile;classAbstractDispatcher{// Declares the interface for the dispatcherpublic:// Declare overloads for each kind of a file to dispatchvirtualvoiddispatch(ArchivedFile&file)=0;virtualvoiddispatch(SplitFile&file)=0;virtualvoiddispatch(ExtractedFile&file)=0;};classArchivedFile:publicFile{// Specific element class #1public:// Resolved at runtime, it calls the dispatcher's overloaded function, corresponding to ArchivedFile.voidaccept(AbstractDispatcher&dispatcher)override{dispatcher.dispatch(*this);}};classSplitFile:publicFile{// Specific element class #2public:// Resolved at runtime, it calls the dispatcher's overloaded function, corresponding to SplitFile.voidaccept(AbstractDispatcher&dispatcher)override{dispatcher.dispatch(*this);}};classExtractedFile:publicFile{// Specific element class #3public:// Resolved at runtime, it calls the dispatcher's overloaded function, corresponding to ExtractedFile.voidaccept(AbstractDispatcher&dispatcher)override{dispatcher.dispatch(*this);}};classDispatcher:publicAbstractDispatcher{// Implements dispatching of all kind of elements (files)public:voiddispatch(ArchivedFile&)override{std::cout<<"dispatching ArchivedFile"<<std::endl;}voiddispatch(SplitFile&)override{std::cout<<"dispatching SplitFile"<<std::endl;}voiddispatch(ExtractedFile&)override{std::cout<<"dispatching ExtractedFile"<<std::endl;}};intmain(){ArchivedFilearchivedFile;SplitFilesplitFile;ExtractedFileextractedFile;std::vector<File*>files;files.push_back(&archivedFile);files.push_back(&splitFile);files.push_back(&extractedFile);Dispatcherdispatcher;for(File*file:files){file->accept(dispatcher);}}

The following example is in the language Java, and shows how the contents of a tree of nodes (in this case describing the components of a car) can be printed. Instead of creating print methods for each node subclass (Wheel, Engine, Body, and Car), one visitor class (CarElementPrintVisitor) performs the required printing action. Because different node subclasses require slightly different actions to print properly, CarElementPrintVisitor dispatches actions based on the class of the argument passed to its visit method. CarElementDoVisitor, which is analogous to a save operation for a different file format, does likewise.

interfaceCarElement{voidaccept(CarElementVisitorvisitor);}interfaceCarElementVisitor{voidvisit(Bodybody);voidvisit(Carcar);voidvisit(Engineengine);voidvisit(Wheelwheel);}classCarimplementsCarElement{CarElement[]elements;publicCar(){this.elements=newCarElement[]{newWheel("front left"),newWheel("front right"),newWheel("back left"),newWheel("back right"),newBody(),newEngine()};}publicvoidaccept(finalCarElementVisitorvisitor){for(CarElementelem:elements){elem.accept(visitor);}visitor.visit(this);}}classBodyimplementsCarElement{publicvoidaccept(finalCarElementVisitorvisitor){visitor.visit(this);}}classEngineimplementsCarElement{publicvoidaccept(finalCarElementVisitorvisitor){visitor.visit(this);}}classWheelimplementsCarElement{privateStringname;publicWheel(finalStringname){this.name=name;}publicStringgetName(){returnname;}publicvoidaccept(finalCarElementVisitorvisitor){/* * accept(CarElementVisitor) in Wheel implements * accept(CarElementVisitor) in CarElement, so the call * to accept is bound at run time. This can be considered * the *first* dispatch. However, the decision to call * visit(Wheel) (as opposed to visit(Engine) etc.) can be * made during compile time since 'this' is known at compile * time to be a Wheel. Moreover, each implementation of * CarElementVisitor implements the visit(Wheel), which is * another decision that is made at run time. This can be * considered the *second* dispatch. */visitor.visit(this);}}classCarElementDoVisitorimplementsCarElementVisitor{publicvoidvisit(finalBodybody){System.out.println("Moving my body");}publicvoidvisit(finalCarcar){System.out.println("Starting my car");}publicvoidvisit(finalWheelwheel){System.out.println("Kicking my "+wheel.getName()+" wheel");}publicvoidvisit(finalEngineengine){System.out.println("Starting my engine");}}classCarElementPrintVisitorimplementsCarElementVisitor{publicvoidvisit(finalBodybody){System.out.println("Visiting body");}publicvoidvisit(finalCarcar){System.out.println("Visiting car");}publicvoidvisit(finalEngineengine){System.out.println("Visiting engine");}publicvoidvisit(finalWheelwheel){System.out.println("Visiting "+wheel.getName()+" wheel");}}publicclassVisitorDemo{publicstaticvoidmain(finalString[]args){finalCarcar=newCar();car.accept(newCarElementPrintVisitor());car.accept(newCarElementDoVisitor());}}

A more flexible approach to this pattern is to create a wrapper class implementing the interface defining the accept method. The wrapper contains a reference pointing to the ICarElement that could be initialized through the constructor. This approach avoids having to implement an interface on each element. See article Java Tip 98 article below

The other-object parameter is superfluous in traverse. The reason is that it is possible to use an anonymous function that calls the desired target method with a lexically captured object:

(defmethodtraverse(function(aauto));; other-object removed(with-slots(elements)a(dolist(eelements)(funcallfunctione))));; from here too;; ...;; alternative way to print-traverse(traverse(lambda(o)(printo*standard-output*))a);; alternative way to do-something with;; elements of a and integer 42(traverse(lambda(o)(do-somethingo42))a)

Now, the multiple dispatch occurs in the call issued from the body of the anonymous function, and so traverse is just a mapping function that distributes a function application over the elements of an object. Thus all traces of the Visitor Pattern disappear, except for the mapping function, in which there is no evidence of two objects being involved. All knowledge of there being two objects and a dispatch on their types is in the lambda function.