双重调度只是使用此模式的原因之一。
但是请注意，这是使用单一调度范式在语言中实现双重或更多调度的唯一方法。
这是使用此模式的原因：
1）我们希望在不每次更改模型的情况下定义新操作，因为模型不会经常更改，而操作会经常更改。
2）我们不想将模型和行为耦合在一起，因为我们想要在多个应用程序中使用可重用的模型，或者希望使用可扩展的模型在一起，，允许客户端类使用自己的类来定义其行为。
3）我们有依赖于模型的具体类型的通用操作，但是我们不想在每个子类中实现逻辑，因为那样会在多个类中以及因此在多个地方爆炸通用逻辑。
4）我们正在使用领域模型设计，并且相同层次结构的模型类执行了太多不同的事情，这些事情可能在其他地方收集到。
5）我们需要双重派遣。
我们有使用接口类型声明的变量，我们希望能够根据其运行时类型来处理它们……当然，无需使用if (myObj instanceof Foo) {}任何技巧。
例如，想法是将这些变量传递给方法，这些方法将接口的具体类型声明为参数以应用特定处理。对于语言而言，这种方式不可能开箱即用，因为它依赖于单调度，因为在运行时调用的所选内容仅取决于接收器的运行时类型。
请注意，在Java中，要调用的方法（签名）是在编译时选择的，它取决于参数的声明类型，而不是参数的运行时类型。
最后一个使用访问者的原因也是一个结果，因为在实现访问者时（当然，对于不支持多调度的语言），您必须引入双重调度实现。
请注意，遍历要在每个对象上应用访问者的元素（迭代）并不是使用模式的原因。
使用模式是因为您拆分了模型和处理。
通过使用该模式，您还可以从迭代器功能中受益。
这种能力非常强大，并且超越accept()了普通方法的通用类型的迭代。
这是一个特殊的用例。因此，我将其放在一边。
Java范例
我将通过一个国际象棋示例来说明该模式的附加值，在该示例中，我们希望在玩家要求移动棋子时定义处理。
如果没有使用访客模式，我们可以直接在件子类中定义件移动行为。
例如，我们可以有一个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()最终都会将当前棋子设置到特定位置，并有可能拿走对手棋子。
将相关行为拆分为多个类，而不是收集它们，以某种方式击败了单一责任模式。使其难以维护。
– 子类可能checkMoveValidity()不会Piece看到或更改的处理内容。
这是超越人为或计算机行为的检查。该检查是在玩家要求的每个动作下执行的，以确保所要求的棋子移动有效。
所以我们甚至不想在Piece界面中提供它。
–在对机器人开发人员具有挑战性的国际象棋游戏中，通常该应用程序提供标准的API（Piece接口，子类，开发板，常见行为等），并使开发人员丰富其机器人策略。
为了做到这一点，我们必须提出一个模型，在该模型中，数据和行为在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);
}
现在定义了作品：
public interface Piece {
void accept(PieceMovingVisitor pieceVisitor);
Coordinates getCoordinates();
void setCoordinates(Coordinates coordinates);
}
其关键方法是：
void accept(PieceMovingVisitor pieceVisitor);
它提供了第一个调度：基于Piece接收方的调用。
在编译时，该方法绑定到accept()Piece接口的方法，并且在运行时，将在运行时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界面必须提供一种方法：
void setCoordinates(Coordinates coordinates);
Piece坐标更改的责任现在对子类以外的其他类开放Piece。
移动访问者在Piece子类中执行的处理也不是一种选择。
的确，由于Piece.accept()接受任何访客实现，这确实会带来另一个问题。它不知道访问者执行什么操作，因此不知道是否以及如何更改Piece状态。
识别访客的一种方法是Piece.accept()根据访客的实现方式执行后处理。这将是一个非常糟糕的主意，因为它会在Visitor实现和Piece子类之间建立高度的耦合，此外，可能还需要使用rick作为getClass()，instanceof或使用任何标记来标识Visitor实现。
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)
