我一直在博客中看到访客模式的参考，但我不得不承认，我就是不明白。我读了维基百科上关于这个模式的文章，我理解了它的机制，但我仍然不知道什么时候使用它。
作为一个最近才真正了解装饰器模式的人，现在看到它在任何地方都有使用，我希望能够真正直观地理解这个看似方便的模式。
当前回答
我真的很喜欢http://python-3-patterns-idioms-test.readthedocs.io/en/latest/Visitor.html上的描述和例子。
The assumption is that you have a primary class hierarchy that is fixed; perhaps it’s from another vendor and you can’t make changes to that hierarchy. However, your intent is that you’d like to add new polymorphic methods to that hierarchy, which means that normally you’d have to add something to the base class interface. So the dilemma is that you need to add methods to the base class, but you can’t touch the base class. How do you get around this? The design pattern that solves this kind of problem is called a “visitor” (the final one in the Design Patterns book), and it builds on the double dispatching scheme shown in the last section. The visitor pattern allows you to extend the interface of the primary type by creating a separate class hierarchy of type Visitor to virtualize the operations performed upon the primary type. The objects of the primary type simply “accept” the visitor, then call the visitor’s dynamically-bound member function.
其他回答
使用访问者模式至少有三个很好的理由:
减少代码的增殖，当数据结构发生变化时，代码只会略有不同。 将相同的计算应用于多个数据结构，而不改变实现计算的代码。 在不更改遗留代码的情况下向遗留库添加信息。
请看看我写的一篇关于这方面的文章。
我发现下面的链接更容易:
在 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)看起来一样，但实际上是不同的，因为它调用不同的访问者重载。
这里的每个人都是对的，但我认为它没有解决“何时”这个问题。首先，从设计模式:
Visitor允许您定义一个新的 操作而不改变类 它所作用的元素。
现在，让我们考虑一个简单的类层次结构。我有类1、2、3和4，方法A、B、C和d。把它们像电子表格一样放出来:类是行，方法是列。
现在，面向对象设计假设您更有可能增长新类而不是新方法，因此添加更多行，可以说，更容易。您只需添加一个新类，指定该类中的不同之处，并继承其余部分。
但是，有时类是相对静态的，但是您需要频繁地添加更多的方法——添加列。面向对象设计的标准方法是将这样的方法添加到所有类中，这可能成本很高。访问者模式使这变得很容易。
顺便说一下，这就是Scala模式匹配想要解决的问题。
