GoF Definition: Represent an operation to be performed on the elements of an object structure. The visitor pattern lets you define a new operation without changing the classes of the elements on which it operates.

Concept

This pattern helps us to add new functionalities to an existing object structure in such a way that the old structure remains unaffected by these changes. So, we can follow the open/close principle here (i.e., extension allowed but modification disallowed for entities like class, function, modules, etc.).

Real-Life Example

Consider a taxi booking scenario. The taxi arrives at our defined location for the pickup. Once we enter into it, the visiting taxi takes control of the transportation. It can choose a different way toward our destination and we may or may not have any prior knowledge of that way.

Computer World Example

This pattern is very useful when plugging happens into public APIs. Clients can then perform operations on a class with a visiting class without modifying the source.

Plugging into public APIs is a common example. Then a client can perform his desired operations without modifying the actual code (with a visiting class).

Illustration

Here we have illustrated a simple example to represent a visitor pattern. In order to do this, we have implemented a new class hierarchy (IVisitor hierarchy) and we have implemented the algorithms there. So, any modification/update operation in the IOriginalInterface hierarchy can be done through this new class hierarchy without affecting the code in the IOriginalInterface hierarchy.

In the following example, we want to modify the initial integer value in MyClass (which implements the Interface IOriginalInterface) through the visitor pattern. Note that we are not touching the code in IOriginalInterface. We are separating functionality implementations (i.e., algorithms) from the class hierarchy where these algorithms operate.

UML Class Diagram

Package Explorer view

High-level structure of the parts of the program is as follows:

Implementation

package visitor.pattern.demo;

interface IOriginalInterface
{
        void accept(IVisitor visitor);
}
class MyClass implements IOriginalInterface
{
        //Initial or default value
        private int myInt = 5;
        public int getMyInt()
        {
                return myInt;
        }

        public void setMyInt(int myInt)
        {
                this.myInt = myInt;
        }

        @Override
        public void accept(IVisitor visitor)
        {
                System.out.println("Initial value of the integer :"+ myInt);
                visitor.visit(this);
                System.out.println("
Value of the integer now :"+ myInt);
        }
}

interface IVisitor
{
        void visit(MyClass myClassElement);
}
class Visitor implements IVisitor
{
        @Override
        public void visit(MyClass myClassElement)
        {
                System.out.println("Visitor is trying to change the integer value");
                myClassElement.setMyInt(100);
                System.out.println("Exiting from Visitor- visit");
        }
}
class VisitorPatternEx
{
        public static void main(String[] args)
        {
                System.out.println("***Visitor Pattern Demo***
");
                IVisitor v = new Visitor();
                MyClass myClass = new MyClass();
                myClass.accept(v);
        }
}

Output

Note

1. As mentioned earlier, the visitor pattern is very useful for adding new operations without affecting the existing structure, which was the key aim behind this pattern.
2. Visitor operations are controlled in a unified manner.
3. On the other hand, the class encapsulation may need to be compromised when visitors are used. If the existing structure is really complex, the traversal mechanism becomes complex.
4. The visitor hierarchy becomes difficult to maintain when we need to add new concrete classes to our existing architecture frequently (e.g., in our program, if we now add Myclass2, we need to add additional operations in the visitor class hierarchy to support this pattern).
5. Sometimes we need to perform some unrelated operations on the objects in the existing architecture. But these operations can directly/indirectly affect the classes in the system. In those situations, this pattern can help us by putting all of these operations in the visitor hierarchy.