Why do we need the visit method in the visitor design pattern?

Question

Why do we need both accept and visit functions in the visitor DP? if we take the typical example:

class Visitor {
  visit(A a) { }
  visit(B b) { }
}

interface Element {
  accept(Visitor v);
}

class A implements Element {
  accept(Visitor v) {
    v.visit(this); // will call visit(A)
  }
}

class B implements Element {
  accept(Visitor v) {
    v.visit(this); // will call visit(B)
  }
}

To use the visitor DP, somewhere we have an instance v of Visitor, and an instance e of Element, and we do:

e.visit(v)

which simply calls

v.visit(e)

so why can't we simply do the second call and bypass the mediator function? Since I think the GoF are not dumb, I guess I'm missing something. What is it?

After reading and re-reading http://stackoverflow.com/questions/255214/when-should-i-use-the-visitor-design-pattern I finally understood when to use the visitor pattern - the answer by @KonradRudolph finally made sense. The problem is that the name of the DP is not very good. — vainolo, Jul 30 '12 at 16:41
Glad to hear you finally got a handle on the pattern, they can indeed sometimes be difficult to grasp. I added more info and a book reference in my answer as it wont fit here. — Brady, Jul 31 '12 at 06:49
@Brady I think the only reason to use this pattern is to implement double dispatch. Using it to visit complex structures is using two patterns: composite and visitor. — vainolo, Jul 31 '12 at 08:26

Brady · Accepted Answer · 2012-07-31T14:46:11.613

Here is an excellent reference for the Visitor pattern, in which they mention the following:

When the accept() method is called in the program, its implementation is chosen based on both:

The dynamic type of the element.

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.

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.)

Consequently, the implementation of the visit() method is chosen based on both:

The dynamic type of the element.

The dynamic type of the visitor.

Then they go on to mention the following:

This effectively implements double dispatch...

In this way, a single algorithm can be written for traversing 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.

Which can be seen in the Java car example:

class Car implements CarElement {
    CarElement[] elements;
    // ...
    public void accept(CarElementVisitor visitor) {     
        for(CarElement elem : elements) {
            elem.accept(visitor);
        }
        visitor.visit(this); 
    }
}

So, to summarize, in your example, you wont get much benefit from the original DP implementation, but if the example is more complex, for example its a Composite with several internal implementations of Element (like the Java car example above), then it can apply the visitor behavior to some or all of its internal elements.

Based on the comments to your original question, there are 2 parts to this pattern:

The original motivation for the pattern: which is to visit a complex structure of objects and perform operations on them without changing the class interfaces being visited.
How the pattern is implemented: which is with the double dispatch as you mention.

I highly recommend the following design patterns book, as it really simplifies many of the concepts. The GoF book is sometimes too academic.

Head First Design Patterns

According to this book, here are the pros and cons to using the Visitor:

(In the context of the example used)

PROs

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

CONs

The Composite classes' encapsulation is broken when the Visitor is used.
Because the traversal function is involved, changes to the Composite structure are more difficult

But I could still do everything without using a visitor pattern, and the could would be easier to understand. — vainolo, Jul 30 '12 at 15:17
@vainolo, I guess you could, you could also write it in assembler :) How would you write the Java Car example without the visitor pattern? To do so, the visitor would then have to know about the internals of the Car class, thus making them tightly coupled. With the pattern, they are completely decoupled. — Brady, Jul 30 '12 at 15:33
Head First Design Patterns: I also highly recommend it, though I don't recall it going into the Visitor Pattern. — Handprint, Jul 31 '12 at 13:17
@Handprint, Look in the Appendix: Leftover Patterns. In my book its on page 628. — Brady, Jul 31 '12 at 14:30

score 0 · Answer 2 · answered Jul 30 '12 at 14:00

Its pretty simple (but perhaps a bit confusing), the whole point of the visitor pattern is to decouple the visitor from the thing being visited.

accept() allows the visited to choose what behavior its going to expose to a visitor of a certain type.

Brady said the same thing, I just wanted to say it in fewer words

Why do we need the visit method in the visitor design pattern?

2 Answers2