Visitor pattern

Visitor Pattern is a way of separating an algorithm from an object structure upon which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. Thus, using the visitor pattern helps conformance with the open/closed principle.

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.

The Visitor must visit each element of the Composite that functionally is in a Traverser object.
Visitor is guided by the Traverser to gather state from all of the objects in the Composite.
Once the state has been gathered, the Client can have the Visitor perform various operations on the state. When new functionality is required, only the Visitor must be enhanced.

Class hierarchy for Visitor Pattern

The idea is to have two class hierarchies

1. One for the elements being operated on, where each element has an "accept" method that takes a visitor object as an argument
   
2. One for the visitors that define operations on the elements. Each visitor has a visit() method for each element class.

The accept() method of the element class calls back the visit() method passing itself as an argument. Here is the UML diagram for the Visitor Pattern, followed by a brief description of the actors involved.

• Visitor: Declares the visit method.
  
• ConcreteVisitor: An implementation of the Visitor interface. May also store state if required.
  
• Element (or Visitable): The interface that declares the accept method. The accept method invokes the visit method passing itself as an argument.
  
• ConcreteElement: Element of the object structure. Has to implement accept method (implements Element).

When to use Visitor Pattern

Use the Visitor pattern when

1. There is a need perform operations that depend on concrete classes of an object structure, and the structure may contain classes of objects with differing interfaces.
   
2. Distinct and unrelated operations must be performed on objects in an object structure, and you want to avoid distributing/replicating similar operations in their classes
   
3. The classes defining the object structure rarely change, but new operations may be added every once in a while.

Visitor Benefits

1. Allows you to add operations to a Composite structure without changing the structure itself. 2. Adding new operations is relatively easy. 3. The code for operations performed by the Visitor is centralized.

Visitor Drawbacks:

1. Encapsulation of the Composite classes is broken when the Visitor is used. 2. Because the traversal function is involved, changes to the Composite structure are more difficult.

Visitor Pattern and Double Dispatch

Double dispatch is a mechanism that allows a function call to change depending on the runtime types of multiple objects involved in the call. In single dipatch a call like Integer.compareTo(Object o), the actual function call depends only on the calling object (the Integer object here). In double dispatch, the actual call may also depend on the object being passed as a parameter to the compareTo method. The most common programming languages (except for LISP) do not have a way for implementing double dispatch. But you may implement double dispatch in these programming languages using the Visitor pattern. You can see the implementation in the following example. Here the call to accept depends not only on the type of object on which it is called (MyLong or MyInteger) but also on the parameter that is being passed to it (AddVisitor and SubtractVisitor).

Example of Visitor Pattern in Java

To implement the Visitor pattern, you create a Visitor interface for the visitor, and a Visitable interface for the item or collection to be visited. Declaring the interfaces

interface Visitor {
public int visit(MyInteger wheel);

public int visit(MyLong engine);
}

interface Visitable {
public int accept(Visitor visitor);
}

Implementation of visitable – MyInteger and MyLong.

class MyInteger implements Visitable {
private int value;

MyInteger(int i) {
this.value = i;
}

public int accept(Visitor visitor) {
return visitor.visit(this);
}

public int getValue() {
return value;
}
}

class MyLong implements Visitable {
private long value;

MyLong(long l) {
this.value = l;
}

public int accept(Visitor visitor) {
return visitor.visit(this);
}

public long getValue() {
return value;
}
}

Implementing the Visitor interface:

class SubtractVisitor implements Visitor {
int value;

public SubtractVisitor(int value) {
this.value = value;
}

public int visit(MyInteger i) {
System.out.println("Subtract integer");
return (i.getValue() - value);
}

public int visit(MyLong l) {
System.out.println("Subtract long");
return ((int) l.getValue() - value);
}

}

class AddVisitor implements Visitor {
int value;

public AddVisitor(int value) {
this.value = value;
}

public int visit(MyInteger i) {
System.out.println("Adding integer");
return (value + i.getValue());
}

public int visit(MyLong l) {
System.out.println("Adding long");
return (value + (int) l.getValue());
}

}

Testing the classes:

public class VisitorTest {
public static void main(String[] args) {
AddVisitor cv = new AddVisitor(10);
SubtractVisitor sv = new SubtractVisitor(10);
MyInteger i = new MyInteger(20);
MyLong l = new MyLong(20);
System.out.println(i.accept(cv));
System.out.println(l.accept(cv));

System.out.println(i.accept(sv));
System.out.println(l.accept(sv));

}
}