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矩阵，双重调度是必要的

这是如何设置看起来像-

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

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

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

我发现下面的链接更容易:

在 http://www.remondo.net/visitor-pattern-example-csharp/我找到了一个例子，展示了一个模拟的例子，展示了什么是访问者模式的好处。这里有不同的Pill容器类:

namespace DesignPatterns
{
    public class BlisterPack
    {
        // Pairs so x2
        public int TabletPairs { get; set; }
    }

    public class Bottle
    {
        // Unsigned
        public uint Items { get; set; }
    }

    public class Jar
    {
        // Signed
        public int Pieces { get; set; }
    }
}

正如你在上面看到的，你BilsterPack包含对药片，所以你需要乘以2对的数量。此外，你可能会注意到瓶使用单位是不同的数据类型，需要强制转换。

所以在主要方法中，您可以使用以下代码计算药丸计数:

foreach (var item in packageList)
{
    if (item.GetType() == typeof (BlisterPack))
    {
        pillCount += ((BlisterPack) item).TabletPairs * 2;
    }
    else if (item.GetType() == typeof (Bottle))
    {
        pillCount += (int) ((Bottle) item).Items;
    }
    else if (item.GetType() == typeof (Jar))
    {
        pillCount += ((Jar) item).Pieces;
    }
}

注意，上面的代码违反了单一责任原则。这意味着如果添加新类型的容器，则必须更改主方法代码。同时，延长开关时间也是不好的做法。

通过引入以下代码:

public class PillCountVisitor : IVisitor
{
    public int Count { get; private set; }

    #region IVisitor Members

    public void Visit(BlisterPack blisterPack)
    {
        Count += blisterPack.TabletPairs * 2;
    }

    public void Visit(Bottle bottle)
    {
        Count += (int)bottle.Items;
    }

    public void Visit(Jar jar)
    {
        Count += jar.Pieces;
    }

    #endregion
}

您将计数药丸数量的责任转移到名为PillCountVisitor的类(并且我们删除了switch case语句)。这意味着每当您需要添加新的药丸容器类型时，您应该只更改PillCountVisitor类。还要注意IVisitor接口一般用于其他场景。

通过在药丸容器类中添加Accept方法:

public class BlisterPack : IAcceptor
{
    public int TabletPairs { get; set; }

    #region IAcceptor Members

    public void Accept(IVisitor visitor)
    {
        visitor.Visit(this);
    }

    #endregion
}

我们允许访客参观药丸容器课程。

最后，我们计算药丸计数使用以下代码:

var visitor = new PillCountVisitor();

foreach (IAcceptor item in packageList)
{
    item.Accept(visitor);
}

这意味着:每个药片容器允许PillCountVisitor访问者查看他们的药片计数。他知道怎么数你的药。

看着来访者。伯爵有药丸的价值。

在 http://butunclebob.com/ArticleS.UncleBob.IuseVisitor你看到了真实的场景，你不能使用多态性(答案)来遵循单一责任原则。事实上在:

public class HourlyEmployee extends Employee {
  public String reportQtdHoursAndPay() {
    //generate the line for this hourly employee
  }
}

reportQtdHoursAndPay方法用于报告和表示，这违反了单一责任原则。因此，最好利用访问者模式来解决这一问题。

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

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

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

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

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

我不理解这种模式，直到我看到bob叔叔的文章和评论。 考虑下面的代码:

public class Employee
{
}

public class SalariedEmployee : Employee
{
}

public class HourlyEmployee : Employee
{
}

public class QtdHoursAndPayReport
{
    public void PrintReport()
    {
        var employees = new List<Employee>
        {
            new SalariedEmployee(),
            new HourlyEmployee()
        };
        foreach (Employee e in employees)
        {
            if (e is HourlyEmployee he)
                PrintReportLine(he);
            if (e is SalariedEmployee se)
                PrintReportLine(se);
        }
    }

    public void PrintReportLine(HourlyEmployee he)
    {
        System.Diagnostics.Debug.WriteLine("hours");
    }
    public void PrintReportLine(SalariedEmployee se)
    {
        System.Diagnostics.Debug.WriteLine("fix");
    }
}

class Program
{
    static void Main(string[] args)
    {
        new QtdHoursAndPayReport().PrintReport();
    }
}

虽然它看起来很好，因为它确认了单一责任，但它违反了开放/封闭原则。每次你有新的员工类型，你将不得不添加如果与类型检查。如果你不知道，在编译时你永远也不会知道。

使用访问者模式，你可以让你的代码更干净，因为它不违反开放/关闭原则，也不违反单一责任。如果你忘记实现visit，它将不会编译:

public abstract class Employee
{
    public abstract void Accept(EmployeeVisitor v);
}

public class SalariedEmployee : Employee
{
    public override void Accept(EmployeeVisitor v)
    {
        v.Visit(this);
    }
}

public class HourlyEmployee:Employee
{
    public override void Accept(EmployeeVisitor v)
    {
        v.Visit(this);
    }
}

public interface EmployeeVisitor
{
    void Visit(HourlyEmployee he);
    void Visit(SalariedEmployee se);
}

public class QtdHoursAndPayReport : EmployeeVisitor
{
    public void Visit(HourlyEmployee he)
    {
        System.Diagnostics.Debug.WriteLine("hourly");
        // generate the line of the report.
    }
    public void Visit(SalariedEmployee se)
    {
        System.Diagnostics.Debug.WriteLine("fix");
    } // do nothing

    public void PrintReport()
    {
        var employees = new List<Employee>
        {
            new SalariedEmployee(),
            new HourlyEmployee()
        };
        QtdHoursAndPayReport v = new QtdHoursAndPayReport();
        foreach (var emp in employees)
        {
            emp.Accept(v);
        }
    }
}

class Program
{

    public static void Main(string[] args)
    {
        new QtdHoursAndPayReport().PrintReport();
    }       
}  
}

神奇的是，虽然v.Visit(this)看起来一样，但实际上是不同的，因为它调用不同的访问者重载。