你困惑的原因可能是来客是一个致命的用词不当。许多(杰出的)程序员都曾遇到过这个问题。它实际做的是用本身不支持它的语言(大多数语言不支持)实现双重调度。

---

1)我最喜欢的例子是《Effective c++》的作者Scott Meyers，他称这是他最重要的c++啊哈之一!的时刻。

双重分派只是使用此模式的众多原因之一。 但请注意，这是在使用单一分派范式的语言中实现双分派或多分派的唯一方法。

以下是使用该模式的原因:

1)我们希望定义新的操作，而不需要每次都改变模型，因为模型不会经常变化，而操作则经常变化。

2)我们不想把模型和行为结合起来，因为我们想要在多个应用程序中有一个可重用的模型，或者我们想要一个可扩展的模型，允许客户端类用它们自己的类定义它们的行为。

3)我们有依赖于模型的具体类型的通用操作，但我们不想在每个子类中实现逻辑，因为这会在多个类中爆炸通用逻辑，因此在多个地方。

4)我们正在使用领域模型设计，相同层次结构的模型类执行太多不同的事情，而这些事情可能会聚集在其他地方。

5) We need a double dispatch. We have variables declared with interface types and we want to be able to process them according their runtime type … of course without using if (myObj instanceof Foo) {} or any trick. The idea is for example to pass these variables to methods that declares a concrete type of the interface as parameter to apply a specific processing. This way of doing is not possible out of the box with languages relies on a single-dispatch because the chosen invoked at runtime depends only on the runtime type of the receiver. Note that in Java, the method (signature) to call is chosen at compile time and it depends on the declared type of the parameters, not their runtime type.

最后一点是使用访问器的一个原因，也是一个后果，因为当您实现访问器时(当然对于不支持多分派的语言)，您必然需要引入双分派实现。

请注意，遍历元素(迭代)以在每个元素上应用访问者并不是使用该模式的原因。 您使用模式是因为您分离了模型和处理。 通过使用该模式，您还可以从迭代器功能中获益。 这种能力非常强大，并且超越了使用特定方法对普通类型进行迭代的能力，因为accept()是一个泛型方法。 这是一个特殊的用例。我先把这个放到一边。

---

Java示例

我将用一个国际象棋的例子来说明该模式的附加价值，在这个例子中，我们想要定义处理，即玩家要求棋子移动。

如果不使用访问者模式，我们可以直接在pieces子类中定义块移动行为。 例如，我们可以有一个Piece接口，如:

public interface Piece{

    boolean checkMoveValidity(Coordinates coord);

    void performMove(Coordinates coord);

    Piece computeIfKingCheck();

}

每个Piece子类将实现它，如:

public class Pawn implements Piece{

    @Override
    public boolean checkMoveValidity(Coordinates coord) {
        ...
    }

    @Override
    public void performMove(Coordinates coord) {
        ...
    }

    @Override
    public Piece computeIfKingCheck() {
        ...
    }

}

对所有Piece子类也是一样的。 下面是一个说明这种设计的图表类:

这种方法有三个重要的缺点:

-行为如performMove()或computeIfKingCheck()将很可能使用公共逻辑。 例如，无论具体的Piece是什么，performMove()最终都会将当前的Piece设置到特定的位置，并可能获取对手的Piece。 将相关的行为拆分到多个类中，而不是将它们聚集在一起，在某种程度上挫败了单一责任模式。使它们的可维护性更加困难。

处理checkMoveValidity()不应该是Piece子类可以看到或改变的东西。 它是超越人类或计算机行为的检查。该检查在玩家请求的每个动作中执行，以确保所请求的棋子移动是有效的。 我们甚至不想在Piece界面中提供这个。

-在对机器人开发者具有挑战性的国际象棋游戏中，应用程序通常提供标准API(棋子接口、子类、棋盘、常见行为等)，并让开发者丰富他们的机器人策略。 为了做到这一点，我们必须提出一个模型，其中数据和行为在Piece实现中不是紧密耦合的。

让我们使用访问者模式!

我们有两种结构:

-接受访问的模型类(碎片)

-拜访他们的访客(移动操作)

下面是说明该模式的类图:

上面的部分是访问者，下面的部分是模型类。

下面是PieceMovingVisitor接口(为每种Piece指定的行为):

public interface PieceMovingVisitor {

    void visitPawn(Pawn pawn);

    void visitKing(King king);

    void visitQueen(Queen queen);

    void visitKnight(Knight knight);

    void visitRook(Rook rook);

    void visitBishop(Bishop bishop);

}

Piece的定义如下:

public interface Piece {

    void accept(PieceMovingVisitor pieceVisitor);

    Coordinates getCoordinates();

    void setCoordinates(Coordinates coordinates);

}

它的关键方法是:

void accept(PieceMovingVisitor pieceVisitor);

它提供了第一个分派:基于Piece接收器的调用。 在编译时，该方法被绑定到Piece接口的accept()方法，在运行时，该绑定方法将在运行时的Piece类上调用。 accept()方法实现将执行第二次分派。

实际上，每个Piece子类都希望被PieceMovingVisitor对象访问，通过传递参数本身来调用PieceMovingVisitor.visit()方法。 通过这种方式，编译器在编译时立即将声明参数的类型与具体类型绑定。 这是第二次调度。 下面是Bishop子类说明了这一点:

public class Bishop implements Piece {

    private Coordinates coord;

    public Bishop(Coordinates coord) {
        super(coord);
    }

    @Override
    public void accept(PieceMovingVisitor pieceVisitor) {
        pieceVisitor.visitBishop(this);
    }

    @Override
    public Coordinates getCoordinates() {
        return coordinates;
    }

   @Override
    public void setCoordinates(Coordinates coordinates) {
        this.coordinates = coordinates;
   }

}

下面是一个用法示例:

// 1. Player requests a move for a specific piece
Piece piece = selectPiece();
Coordinates coord = selectCoordinates();

// 2. We check with MoveCheckingVisitor that the request is valid
final MoveCheckingVisitor moveCheckingVisitor = new MoveCheckingVisitor(coord);
piece.accept(moveCheckingVisitor);

// 3. If the move is valid, MovePerformingVisitor performs the move
if (moveCheckingVisitor.isValid()) {
    piece.accept(new MovePerformingVisitor(coord));
}

游客的缺点

访问者模式是一种非常强大的模式，但它也有一些重要的限制，在使用它之前应该考虑这些限制。

1)降低/破坏封装的风险

在某些类型的操作中，访问者模式可能会减少或破坏域对象的封装。

例如，MovePerformingVisitor类需要设置实际piece的坐标，piece接口必须提供一种方法来做到这一点:

void setCoordinates(Coordinates coordinates);

The responsibility of Piece coordinates changes is now open to other classes than Piece subclasses. Moving the processing performed by the visitor in the Piece subclasses is not an option either. It will indeed create another issue as the Piece.accept() accepts any visitor implementation. It doesn't know what the visitor performs and so no idea about whether and how to change the Piece state. A way to identify the visitor would be to perform a post processing in Piece.accept() according to the visitor implementation. It would be a very bad idea as it would create a high coupling between Visitor implementations and Piece subclasses and besides it would probably require to use trick as getClass(), instanceof or any marker identifying the Visitor implementation.

2)变更模型的要求

与Decorator等其他行为设计模式相反，访问者模式是侵入式的。 我们确实需要修改初始接收者类，以提供一个accept()方法来接受访问。 对于Piece和它的子类，我们没有任何问题，因为这些是我们的类。 在内置类或第三方类中，事情就不那么容易了。 我们需要包装或继承(如果可以的话)它们来添加accept()方法。

3)间接

该模式创建多个间接点。 双分派意味着两次调用而不是一次调用:

call the visited (piece) -> that calls the visitor (pieceMovingVisitor)

当访问者改变被访问对象的状态时，我们可以有额外的间接指示。 它可能看起来像一个循环:

call the visited (piece) -> that calls the visitor (pieceMovingVisitor) -> that calls the visited (piece)

使用访问者模式至少有三个很好的理由:

减少代码的增殖，当数据结构发生变化时，代码只会略有不同。 将相同的计算应用于多个数据结构，而不改变实现计算的代码。 在不更改遗留代码的情况下向遗留库添加信息。

请看看我写的一篇关于这方面的文章。

正如Konrad Rudolph已经指出的，它适用于需要双重调度的情况

这里有一个例子，以显示我们需要双重调度&访客如何帮助我们这样做的情况。

例子:

假设我有三种类型的移动设备——iPhone, Android, Windows mobile。

这三种设备都安装了蓝牙收音机。

让我们假设蓝牙收音机可以来自2个独立的原始设备制造商-英特尔和博通。

为了使这个例子与我们的讨论相关，我们还假设Intel电台公开的api与Broadcom电台公开的api是不同的。

这是我的类的样子

现在，我想介绍一个操作——移动设备蓝牙开关。

它的函数特征应该是这样的

 void SwitchOnBlueTooth(IMobileDevice mobileDevice, IBlueToothRadio blueToothRadio)

因此，根据正确的设备类型和蓝牙收音机的正确类型，它可以通过调用适当的步骤或算法打开。

原则上，它变成了一个3 × 2的矩阵，在这里，我试图根据所涉及的对象的正确类型来进行正确的操作。

取决于两个参数类型的多态行为。

现在，访问者模式可以应用于这个问题。灵感来自维基百科页面上的说明——“本质上，访问者允许在不修改类本身的情况下向类族添加新的虚函数;相反，创建一个实现虚函数的所有适当专门化的访问者类。访问者将实例引用作为输入，通过双重调度实现目标。

由于3x2矩阵，双重调度是必要的

这是如何设置看起来像-

我写了一个例子来回答另一个问题，代码和它的解释在这里被提到。

这里的每个人都是对的，但我认为它没有解决“何时”这个问题。首先，从设计模式:

Visitor允许您定义一个新的 操作而不改变类 它所作用的元素。

现在，让我们考虑一个简单的类层次结构。我有类1、2、3和4，方法A、B、C和d。把它们像电子表格一样放出来:类是行，方法是列。

现在，面向对象设计假设您更有可能增长新类而不是新方法，因此添加更多行，可以说，更容易。您只需添加一个新类，指定该类中的不同之处，并继承其余部分。

但是，有时类是相对静态的，但是您需要频繁地添加更多的方法——添加列。面向对象设计的标准方法是将这样的方法添加到所有类中，这可能成本很高。访问者模式使这变得很容易。

顺便说一下，这就是Scala模式匹配想要解决的问题。

在我看来，使用访问者模式或直接修改每个元素结构添加新操作的工作量大致相同。此外，如果我要添加新的元素类，比如Cow，操作接口将受到影响，并且这将传播到所有现有的元素类，因此需要重新编译所有元素类。那么重点是什么呢?