What is the need for `accept` method in Visitor pattern

Viewed 800

I'm looking at the explanation of the visitor pattern here which shows the following code:

public class ShoppingCart {
  public double calculatePostage() {
    PostageVisitor visitor = new PostageVisitor();
    for(Visitable item: items) {
      item.accept(visitor);
    }

public class PostageVisitor implements Visitor {
  public void visit(Book book) {

public class Book implements Visitable{
  public void accept(Visitor vistor) {
    visitor.visit(this);
  }

From the standpoint of JavaScript developer the accept method seems redundant since the code could be written like this:

for(Visitable item: items) {
   // directly call visitor passing an item instead of doing so through `accept` method
   visitor.visit(item);  
}

Am I right to assume that this won't work because the compiler doesn't know which overloaded visit method of the visitor to execute?

As I understand the compiler understands which visit method to execute on the visitor with accept since it can match the type of this passed to the visitor.visit(this) method here:

public void accept(Visitor vistor) {
    visitor.visit(this);
}

Edit:

Just found that in addition to the great answers here this answer also provides a lot of useful details.

2 Answers

Am I right to assume that this won't work because the compiler doesn't know which overloaded visit method of the visitor to execute?

Absolutely. Visitor is for double-dispatch; accept executes the first leg of dispatch, because it is virtual on the item. The code inside accept executes the second leg of dispatch by letting the compiler pick the proper overload.

As I understand the compiler understands which visit method to execute on the visitor with accept since it can match the type of this passed to the visitor.visit(this)

This is exactly right. I think the part that is confusing in this implementation of the visitor is the overload. It is much easier to see what's going on when instead of overloading visit you give each overload a separate name. In other words, instead of

public void visit(Book book);
public void visit(Cow cow);
public void visit(Island island);

you write

public void visitBook(Book book);
public void visitCow(Cow cow);
public void visitIsland(Island island);

From the standpoint of JavaScript developer the accept method seems redundant since the code could be written like this:

for(Visitable item: items) {
    // directly call visitor passing an item instead of doing so through `accept` method
    visitor.visit(item);  
}

The code couldn't be written like that in JavaScript. To see why, let's first look at what the visitor looks like. In Java, it'd look like this:

void visit(Book book) { ... }
void visit(OtherThing otherThing) {...}

JavaScript doesn't have overloading like this, so the different visit methods would need different names. So it'd would look like this instead:

function visitBook(book) { ... }
function visitOtherThing(otherThing) { ... }

Now you clearly can't do visitor.visit(item) because there is no visit method. There are visitBook and visitOtherThing, but you don't know which of those to call because you don't what type of item you have. So you still need an accept method. Then a book's accept method would call visitBook and an OtherThing's accept method would call visitOtherThing.

This is, in fact, what the visitor pattern in JavaScript usually looks like.

Am I right to assume that this won't work because the compiler doesn't know which overloaded visit method of the visitor to execute?

Yes.

As I understand the compiler understands which visit method to execute on the visitor with accept since it can match the type of this passed to the visitor.visit(this) method here

Exactly.

Related