Reputation: 6987
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
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:
I highly recommend the following design patterns book, as it really simplifies many of the concepts. The GoF book is sometimes too academic.
According to this book, here are the pros and cons to using the Visitor:
(In the context of the example used)
PROs
CONs
Upvotes: 4
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