1. Overview
In this tutorial, we’ll introduce one of the behavioral GoF design patterns – the Visitor.
First, we’ll explain its purpose and the problem it tries to solve.
Next, we’ll have a look at Visitor’s UML diagram and implementation of the practical example.
2. Visitor Design Pattern
The purpose of a Visitor pattern is to define a new operation without introducing the modifications to an existing object structure.
Imagine that we have a composite object which consists of components. The object’s structure is fixed – we either can’t change it, or we don’t plan to add new types of elements to the structure.
Now, how could we add new functionality to our code without modification of existing classes?
The Visitor design pattern might be an answer. Simply put, we’ll have to do is to add a function which accepts the visitor class to each element of the structure.
That way our components will allow the visitor implementation to “visit” them and perform any required action on that element.
In other words, we’ll extract the algorithm which will be applied to the object structure from the classes.
Consequently, we’ll make good use of the Open/Closed principle as we won’t modify the code, but we’ll still be able to extend the functionality by providing a new Visitor implementation.
3. UML Diagram
On the UML diagram above, we have two implementation hierarchies, specialized visitors, and concrete elements.
First of all, the client uses a Visitor implementation and applies it to the object structure. The composite object iterates over its components and applies the visitor to each of them.
Now, especially relevant is that concrete elements (ConcreteElementA and ConcreteElementB) are accepting a Visitor, simply allowing it to visit them.
Lastly, this method is the same for all elements in the structure, it performs double dispatch with passing itself (via the this keyword) to the visitor’s visit method.
4. Implementation
Our example will be custom Document object that consists of JSON and XML concrete elements; the elements have a common abstract superclass, the Element.
The Document class:
public class Document extends Element {
List<Element> elements = new ArrayList<>();
// ...
@Override
public void accept(Visitor v) {
for (Element e : this.elements) {
e.accept(v);
}
}
}
The Element class has an abstract method which accepts the Visitor interface:
public abstract void accept(Visitor v);
Therefore, when creating the new element, name it the JsonElement, we’ll have to provide the implementation this method.
However, due to nature of the Visitor pattern, the implementation will be the same, so in most cases, it would require us to copy-paste the boilerplate code from other, already existing element:
public class JsonElement extends Element {
// ...
public void accept(Visitor v) {
v.visit(this);
}
}
Since our elements allow visiting them by any visitor, let’s say that we want to process our Document elements, but each of them in a different way, depending on its class type.
Therefore, our visitor will have a separate method for the given type:
public class ElementVisitor implements Visitor {
@Override
public void visit(XmlElement xe) {
System.out.println(
"processing an XML element with uuid: " + xe.uuid);
}
@Override
public void visit(JsonElement je) {
System.out.println(
"processing a JSON element with uuid: " + je.uuid);
}
}
Here, our concrete visitor implements two methods, correspondingly one per each type of the Element.
This gives us access to the particular object of the structure on which we can perform necessary actions.
5. Testing
For testing purpose, let’s have a look at VisitorDemoclass:
public class VisitorDemo {
public static void main(String[] args) {
Visitor v = new ElementVisitor();
Document d = new Document(generateUuid());
d.elements.add(new JsonElement(generateUuid()));
d.elements.add(new JsonElement(generateUuid()));
d.elements.add(new XmlElement(generateUuid()));
d.accept(v);
}
// ...
}
First, we create an ElementVisitor, it holds the algorithm we will apply to our elements.
Next, we set up our Document with proper components and apply the visitor which will be accepted by every element of an object structure.
The output would be like this:
processing a JSON element with uuid: fdbc75d0-5067-49df-9567-239f38f01b04
processing a JSON element with uuid: 81e6c856-ddaf-43d5-aec5-8ef977d3745e
processing an XML element with uuid: 091bfcb8-2c68-491a-9308-4ada2687e203
It shows that visitor has visited each element of our structure, depending on the Element type, it dispatched the processing to appropriate method and could retrieve the data from every underlying object.
6. Downsides
As each design pattern, even the Visitor has its downsides, particularly, its usage makes it more difficult to maintain the code if we need to add new elements to the object’s structure.
For example, if we add new YamlElement, then we need to update all existing visitors with the new method desired for processing this element. Following this further, if we have ten or more concrete visitors, that might be cumbersome to update all of them.
Other than this, when using this pattern, the business logic related to one particular object gets spread over all visitor implementations.
7. Conclusion
The Visitor pattern is great to separate the algorithm from the classes on which it operates. Besides that, it makes adding new operation more easily, just by providing a new implementation of the Visitor.
Furthermore, we don’t depend on components interfaces, and if they are different, that’s fine, since we have a separate algorithm for processing per concrete element.
Moreover, the Visitor can eventually aggregate data based on the element it traverses.
To see a more specialized version of the Visitor design pattern, check out visitor pattern in Java NIO – the usage of the pattern in the JDK.
As usual, the complete code is available on the Github project.