访客模式和双重调度

Question

我知道这是一个经常被人涉足的领域，但我有一个具体的问题......我保证。

我在静态类型、面向对象的世界中花了很少的时间，最近在阅读 制作解释器。虽然我理解这种模式允许在一组定义良好的现有类型（类）上进行可扩展的行为（方法），但我不太明白它的特征双重调度问题的解决方案，至少在没有一些额外假设的情况下。我认为它更多地是对 表达式问题 的权衡，即用封闭类型换取开放类型方法。

在我见过的大多数例子中，你最终会得到这样的结果（无耻地从很棒的 Clojure 设计模式）

public interface Visitor {
  void visit(Activity a);
  void visit(Message m);
}

public class PDFVisitor implements Visitor {
  @Override
  public void visit(Activity a) {
    PDFExporter.export(a);
  }

  @Override
  public void visit(Message m) {
    PDFExporter.export(m);
  }
}

public abstract class Item {
  abstract void accept(Visitor v);
}

class Message extends Item {
  @Override
  void accept(Visitor v) {
    v.visit(this);
  }
}

class Activity extends Item {
  @Override
  void accept(Visitor v) {
    v.visit(this);
  }
}

Item i = new Message();
Visitor v = new PDFVisitor(); 
i.accept(v);

这里我们有一组可能是关闭的或不经常更改的类型（消息和活动），以及一组我们想要的方法开放延期（访客）。现在让我感到困惑的是，在大多数示例中，他们将展示如何在不接触现有类的情况下实现其他访问者，例如这样的东西：

public class XMLVisitor implements Visitor {
  @Override
  public void visit(Activity a) {
    XMLExporter.export(a);
  }

  @Override
  public void visit(Message m) {
    XMLExporter.export(m);
  }
}

然后手动暗示这是“双重调度”，但它不是。 这里 accept 动态地分派 Item 的子类型，但在 accept 中，visit 方法静态分派给传入的通过方法重载的访问者。因此，我们对 Item 进行单一调度，然后 accept 中的“第二个”静态调度实际上是选择一个行为（方法）来调用该 Item< /代码> 类型。只有一种“类型”被调度，而不是两种 - 第二种是行为。

当我想到双重分派时，我想到的是根据两个参数的类型分派的函数。一种行为，两种类型。

export(Activity,XML)
export(Activity,PDF)
export(Message,XML)
export(Message,PDF)

对我来说，这与访问者模式略有不同，访问者模式允许将任何行为集扩展到现有类，但这些行为不一定都代表相同的行为，如上面的四个 export 示例 -它们可以是任何东西。如果我们添加另一个访客，它可能代表导出，但也可能不代表导出。从 API 层，您只需调用 accept 方法并相信传入的 Visitor 会执行您想要的操作，无论是什么。

我是否以错误的方式看待这个问题？

Answer 1

@user207421 的评论很到位。如果一种语言本身不支持双重调度，则任何设计模式都无法改变该语言以使其支持。模式仅提供一种替代方案，可以解决双分派在另一种语言中应用的一些问题。

已经了解双重调度的学习访问者模式的人可能会得到诸如“访问者解决了与双重调度解决的类似问题”之类的解释的帮助。不幸的是，这种解释常常被简化为“访问者实现双重调度”，这是不正确的。

您认识到这一点意味着您已经对这两个概念有了深入的了解。