我一直在博客中看到访客模式的参考，但我不得不承认，我就是不明白。我读了维基百科上关于这个模式的文章，我理解了它的机制，但我仍然不知道什么时候使用它。
作为一个最近才真正了解装饰器模式的人，现在看到它在任何地方都有使用，我希望能够真正直观地理解这个看似方便的模式。
当前回答
使用访问者模式至少有三个很好的理由:
减少代码的增殖，当数据结构发生变化时，代码只会略有不同。 将相同的计算应用于多个数据结构，而不改变实现计算的代码。 在不更改遗留代码的情况下向遗留库添加信息。
请看看我写的一篇关于这方面的文章。
其他回答
Visitor设计模式非常适用于目录树、XML结构或文档概要等“递归”结构。
Visitor对象访问递归结构中的每个节点:每个目录、每个XML标记等等。Visitor对象不遍历结构。相反，Visitor方法应用于结构的每个节点。
这是一个典型的递归节点结构。可以是目录或XML标记。 [如果你是一个Java人，想象一下有很多额外的方法来构建和维护子列表。]
class TreeNode( object ):
def __init__( self, name, *children ):
self.name= name
self.children= children
def visit( self, someVisitor ):
someVisitor.arrivedAt( self )
someVisitor.down()
for c in self.children:
c.visit( someVisitor )
someVisitor.up()
visit方法将Visitor对象应用于结构中的每个节点。在本例中，它是一个自顶向下的访问者。您可以更改visit方法的结构，以进行自底向上或其他排序。
这里有一个供访问者使用的超类。它被visit方法所使用。它“到达”结构中的每个节点。由于visit方法调用了up和down，因此访问者可以跟踪深度。
class Visitor( object ):
def __init__( self ):
self.depth= 0
def down( self ):
self.depth += 1
def up( self ):
self.depth -= 1
def arrivedAt( self, aTreeNode ):
print self.depth, aTreeNode.name
子类可以做一些事情，比如在每个级别上计算节点并积累一个节点列表，生成一个良好的路径分层节号。
这是申请表。它构建了一个树结构，someTree。它创建了一个Visitor, dumpNodes。
然后它将dumpNodes应用到树中。dumpNode对象将“访问”树中的每个节点。
someTree= TreeNode( "Top", TreeNode("c1"), TreeNode("c2"), TreeNode("c3") )
dumpNodes= Visitor()
someTree.visit( dumpNodes )
TreeNode访问算法将确保每个TreeNode都被用作Visitor的arrivedAt方法的参数。
在我看来，使用访问者模式或直接修改每个元素结构添加新操作的工作量大致相同。此外，如果我要添加新的元素类，比如Cow，操作接口将受到影响，并且这将传播到所有现有的元素类，因此需要重新编译所有元素类。那么重点是什么呢?
Cay Horstmann在他的OO设计和模式书中有一个很好的例子，说明了在哪里应用Visitor。他总结了这个问题:
复合对象通常具有复杂的结构，由单个元素组成。有些元素可能也有子元素. ...元素上的操作访问它的子元素，对它们应用该操作，并将结果组合在一起. ...然而，向这样的设计中添加新的操作并不容易。
不容易的原因是，操作是在结构类本身中添加的。例如，假设你有一个文件系统:
下面是一些我们可能想用这个结构实现的操作(功能):
显示节点元素的名称(一个文件列表) 显示计算出的节点元素大小(其中目录的大小包括其所有子元素的大小) 等。
You could add functions to each class in the FileSystem to implement the operations (and people have done this in the past as it's very obvious how to do it). The problem is that whenever you add a new functionality (the "etc." line above), you might need to add more and more methods to the structure classes. At some point, after some number of operations you've added to your software, the methods in those classes don't make sense anymore in terms of the classes' functional cohesion. For example, you have a FileNode that has a method calculateFileColorForFunctionABC() in order to implement the latest visualization functionality on the file system.
The Visitor Pattern (like many design patterns) was born from the pain and suffering of developers who knew there was a better way to allow their code to change without requiring a lot of changes everywhere and also respecting good design principles (high cohesion, low coupling). It's my opinion that it's hard to understand the usefulness of a lot of patterns until you've felt that pain. Explaining the pain (like we attempt to do above with the "etc." functionalities that get added) takes up space in the explanation and is a distraction. Understanding patterns is hard for this reason.
Visitor allows us to decouple the functionalities on the data structure (e.g., FileSystemNodes) from the data structures themselves. The pattern allows the design to respect cohesion -- data structure classes are simpler (they have fewer methods) and also the functionalities are encapsulated into Visitor implementations. This is done via double-dispatching (which is the complicated part of the pattern): using accept() methods in the structure classes and visitX() methods in the Visitor (the functionality) classes:
这个结构允许我们添加新的功能，这些功能作为具体的访问者在结构上工作(不需要改变结构类)。
例如，PrintNameVisitor实现目录列表功能，PrintSizeVisitor实现具有大小的版本。我们可以想象有一天有一个以XML生成数据的“ExportXMLVisitor”，或者另一个以JSON生成数据的访问者，等等。我们甚至可以让一个访问者使用图形化语言(如DOT)显示我的目录树，然后用另一个程序进行可视化。
最后要注意的是:Visitor的双重分派的复杂性意味着它更难以理解、编码和调试。简而言之，它有很高的极客因素，违背了KISS原则。在研究人员进行的一项调查中，访问者被证明是一个有争议的模式(关于它的有用性没有达成共识)。一些实验甚至表明，它并没有使代码更容易维护。
正如Konrad Rudolph已经指出的，它适用于需要双重调度的情况
这里有一个例子，以显示我们需要双重调度&访客如何帮助我们这样做的情况。
例子:
假设我有三种类型的移动设备——iPhone, Android, Windows mobile。
这三种设备都安装了蓝牙收音机。
让我们假设蓝牙收音机可以来自2个独立的原始设备制造商-英特尔和博通。
为了使这个例子与我们的讨论相关，我们还假设Intel电台公开的api与Broadcom电台公开的api是不同的。
这是我的类的样子
现在，我想介绍一个操作——移动设备蓝牙开关。
它的函数特征应该是这样的
void SwitchOnBlueTooth(IMobileDevice mobileDevice, IBlueToothRadio blueToothRadio)
因此，根据正确的设备类型和蓝牙收音机的正确类型，它可以通过调用适当的步骤或算法打开。
原则上，它变成了一个3 × 2的矩阵，在这里，我试图根据所涉及的对象的正确类型来进行正确的操作。
取决于两个参数类型的多态行为。
现在，访问者模式可以应用于这个问题。灵感来自维基百科页面上的说明——“本质上，访问者允许在不修改类本身的情况下向类族添加新的虚函数;相反，创建一个实现虚函数的所有适当专门化的访问者类。访问者将实例引用作为输入，通过双重调度实现目标。
由于3x2矩阵，双重调度是必要的
这是如何设置看起来像-
我写了一个例子来回答另一个问题，代码和它的解释在这里被提到。
访问者模式作为方面对象编程的地下实现。
例如，如果您定义一个新操作，而不改变其操作的元素的类
