vainolo
vainolo

Reputation: 6987

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

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?

Upvotes: 4

Views: 2102

Answers (2)

Brady
Brady

Reputation: 10357

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:

  1. 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.
  2. 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

Upvotes: 4

deleted_user
deleted_user

Reputation: 3805

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

Upvotes: 0

Related Questions