GoF Definition

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.

Concept

This pattern helps you add new operations on the objects without modifying the corresponding classes, especially when your operations change very often. Ideally, visitors define class-specific methods, which work with an object of that class to support new functionalities. Here you separate an algorithm from an object structure, and you add new operations using a new hierarchy. Therefore, this pattern can support the open/close principle (extension is allowed but modification is disallowed for entities like class, function, modules, etc.). The upcoming implementations will make the concept clearer to you.

Real-World Example

Think of a taxi-booking scenario. When the tax arrives and you get into it, the taxi driver takes the control of the transportation. The taxi may take you to your destination through a new route that you are not familiar with. So, you can explore the new route with the help of the taxi driver. But you should use the visitor pattern carefully, otherwise, you may encounter some problem. (For example, consider a case when your taxi driver alters the destination unknowingly, and you face the trouble).

Computer-World Example

This pattern is very useful when public APIs need to support plugging operations. Clients can then perform their intended operations on a class (with the visiting class) without modifying the source.

Illustration

Here our discussion will start with a simple example of the visitor design pattern. Let’s assume that you have an inheritance hierarchy where a MyClass concrete class implements the OriginalInterface interface. MyClass has an integer, myInt. When you create an instance of MyClass, it is initialized with a value, 5. Now suppose, you want to update this initialized value and display it. You can do it in two different ways: you can add a method inside MyClass to do your job or use a visitor pattern, which I am about to explain.

In the following implementation, I am multiplying the existing value by 2 and displaying this double value of myInt using the visitor design pattern. If I do not use this pattern, I need to add an operation (or method) inside MyClass, which does the same.

But there is a problem with the later approach. If you want to further update the logic (e.g., you want to triple myInt and display the value), you need to modify the operation in MyClass. One drawback with this approach is that if there are many classes involved, it will be tedious to implement this updated logic in all of them.

But in a visitor pattern, you can just update the visitor’s method. The advantage is that you do not need to change the original classes. This approach helps you when your operations change quite often.

So, let’s start with an example. Let’s assume that in this example, you want to double the initial integer value in MyClass and manipulate it, but your constraint is that you cannot change the original codes in the OriginalInterface hierarchy. So, you are using a visitor pattern in this case.

To achieve the goal, in the following example, I am separating the functionality implementations (i.e., algorithms) from the original class hierarchy.

Class Diagram

Figure 13-1 shows the class diagram.

Package Explorer View

Figure 13-2 shows the high-level structure of the program.

Modified Illustration

You have already seen a very simple example of the visitor design pattern. But you can exercise the true power of this design pattern when you combine it with the composite pattern (see Chapter 11). So, let’s examine a scenario where you need to combine both the composite pattern and the visitor pattern.

Key Characteristic of the Modified Example

Let’s revisit the example of our composite design pattern from Chapter 11. In that example, there is a college with two different departments. Each of these departments has one head of department (HOD) and multiple teachers (or professors/lecturers). Each HOD reports to the principal of the college. Figure 13-3 shows the tree structure that I discussed in that chapter.

Now suppose that the principal of the college wants to promote a few employees. Let’s consider that teaching experience is the only criteria to promote someone. Ideally, the criteria should vary among senior teachers and junior teachers. So, let’s assume that for a junior teacher, the minimum criteria for promotion is 12 years and for senior teachers, it is 15 years.

To accomplish this, you need to introduce a new field, yearsOfExperience. So, when a visitor gathers the necessary information from the college, it shows the eligible candidates for promotion.

The visitor is collecting the data from the original college structure without making any modifications to it, and once the collection process is over, it analyses the data to display the intended results. To understand this visually, you can follow the arrows in the upcoming figures. The principal is at the top of the organization, so you can assume that no promotion is required for that person.

Step 1

Figure 13-4 shows step 1.

Step 2

Figure 13-5 shows step 2.

Step 3

Figure 13-6 shows step 3.

Step 4

Figure 13-7 shows step 4.

Step 5

Figure 13-8 shows step 5.

And so on…

In the following implementation, there are code blocks like the following.

@Override

public void acceptVisitor(Visitor visitor)

{

    visitor.visitTheElement(this);

}

From this structure, you can see two important things.

• Each time a visitor visits a particular object, the object invokes a method on the visitor, passing itself as an argument. The visitor has methods that are specific to a particular class.

• Objects of the concrete employee classes (CompositeEmployee, SimpleEmployee) only implement the acceptVisitor(Visitor visitor) method. These objects know about the specific method of the visitor (which is passed as an argument here) that it should invoke.

So, let’s start.

Modified Class Diagram

Figure 13-9 shows the modified class diagram.

Modified Package Explorer View

Figure 13-10 shows the high-level structure of the modified program.

Q&A Session