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

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

你的问题是什么时候知道:

我不首先编码访问者模式。我编写标准代码，等待需求的出现，然后重构。假设你有多个支付系统，一次安装一个。在签出时，你可以有很多if条件(或instanceOf)，例如:

//psuedo code
    if(payPal) 
    do paypal checkout 
    if(stripe)
    do strip stuff checkout
    if(payoneer)
    do payoneer checkout

现在假设我有10种支付方式，这有点难看。因此，当你看到这种模式发生时，访问者会很容易地将所有这些分离出来，然后你最终会调用这样的东西:

new PaymentCheckoutVistor(paymentType).visit()

你可以看到如何实现它从这里的例子的数量，我只是向你展示一个用例。

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原则。在研究人员进行的一项调查中，访问者被证明是一个有争议的模式(关于它的有用性没有达成共识)。一些实验甚至表明，它并没有使代码更容易维护。

一种看待它的方法是，访问者模式是一种让客户端向特定类层次结构中的所有类添加额外方法的方式。

当您有一个相当稳定的类层次结构，但您对需要对该层次结构做什么有不断变化的需求时，它是有用的。

经典的例子是编译器之类的。抽象语法树(AST)可以准确地定义编程语言的结构，但是您可能希望在AST上执行的操作将随着项目的进展而变化:代码生成器、漂亮的打印机、调试器、复杂性度量分析。

如果没有访问者模式，每次开发人员想要添加一个新特性时，他们都需要将该方法添加到基类中的每个特性中。当基类出现在单独的库中或由单独的团队生成时，这尤其困难。

(我听说访问者模式与良好的OO实践相冲突，因为它将数据的操作从数据中移开了。访问者模式在正常的OO实践失败的情况下非常有用。)

我不太熟悉来客模式。看看我做得对不对。假设你有一个动物等级

class Animal {  };
class Dog: public Animal {  };
class Cat: public Animal {  };

(假设它是一个具有良好接口的复杂层次结构。)

现在我们想要向层次结构添加一个新操作，即我们想要每个动物发出它的声音。既然层次结构这么简单，你可以直接用多态性来实现:

class Animal
{ public: virtual void makeSound() = 0; };

class Dog : public Animal
{ public: void makeSound(); };

void Dog::makeSound()
{ std::cout << "woof!\n"; }

class Cat : public Animal
{ public: void makeSound(); };

void Cat::makeSound()
{ std::cout << "meow!\n"; }

但是按照这种方式进行，每次想要添加操作时，都必须修改到层次结构中每个类的接口。现在，假设您对原始界面感到满意，并且希望对其进行尽可能少的修改。

访问者模式允许您在合适的类中移动每个新操作，并且您只需要扩展层次结构的接口一次。我们开始吧。首先，我们定义了一个抽象操作(GoF中的“Visitor”类)，它对层次结构中的每个类都有一个方法:

class Operation
{
public:
    virtual void hereIsADog(Dog *d) = 0;
    virtual void hereIsACat(Cat *c) = 0;
};

然后，我们修改层次结构以接受新的操作:

class Animal
{ public: virtual void letsDo(Operation *v) = 0; };

class Dog : public Animal
{ public: void letsDo(Operation *v); };

void Dog::letsDo(Operation *v)
{ v->hereIsADog(this); }

class Cat : public Animal
{ public: void letsDo(Operation *v); };

void Cat::letsDo(Operation *v)
{ v->hereIsACat(this); }

最后，我们实现了实际的操作，没有修改Cat和Dog:

class Sound : public Operation
{
public:
    void hereIsADog(Dog *d);
    void hereIsACat(Cat *c);
};

void Sound::hereIsADog(Dog *d)
{ std::cout << "woof!\n"; }

void Sound::hereIsACat(Cat *c)
{ std::cout << "meow!\n"; }

现在，您可以在不修改层次结构的情况下添加操作。 下面是它的工作原理:

int main()
{
    Cat c;
    Sound theSound;
    c.letsDo(&theSound);
}

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