当我读到访问者模式时，它说像
允许在运行时将一个或多个操作应用于一组对象，从而将操作与对象结构分离。
如果我的假设是正确的，我们将定义一个抽象访问者，其中包含处理每个对象的方法。然后具体的访问者将实现这些方法中的每一个。通过这种方式，我们将处理对象的逻辑从 Object 类分离到访问者实现。
我怀疑如果我们只有一个访问者实现，我们真的需要使用这种模式吗？我们不能把实现放在每个 Object 类中直接调用吗？如果我在两者之间遗漏了什么，请纠正我。
【问题讨论】：
标签： design-patterns visitor-pattern
实际上，您从来没有真正需要使用这种模式或任何其他模式。如果您使用模式是因为您正在根据您的上下文做出设计选择。
模式文档的几项旨在帮助您做出有关是否使用该模式的明智决定。特别要检查以下部分：
如果您处于从对象结构解耦操作中受益的上下文中，可能是因为将来会有新的操作应用于这些对象，该模式将改进您的设计。如果您处于生命周期有限的小程序的上下文中，则该模式可能会产生开销。
因此，请再次阅读模式文档，检查您的软件上下文，并就是否使用它做出明智的决定。
【讨论】：
我不同意。
将逻辑放在对象中而不是放在访问者中并不总是可能或可取的。例如，作为“域”层的一部分的持久实体（用户或订单）不一定有权访问（或不应该有权访问）服务（“服务”层的一部分）是执行操作所必需的：为订单计费，或提升用户。
另外，仅仅因为现在只有一个访问者并不意味着其他人以后不会出现。
模式的目标是解耦。通过将操作放在访问对象本身中，您不再需要解耦。
通过解耦，您还创建了一个可重用的 API。使用您的类的开发人员很可能无法修改它们，因为他/她根本没有源代码，因此无法更改它。然而，它必须能够根据对象的实际具体类做一些不同的事情。因此访问者模式。
【讨论】：
您对访问者模式的描述说明了一切：
从对象结构中解耦操作
在一个良好解耦的世界中，您将拥有保存数据的对象和对数据进行操作的对象。访问者模式的目标是解耦这些。这可能不是您会经常明确看到的模式，但是您会随处看到的底层主体。
通过解耦操作，您可以使用 SOLID (Open/Closed Principle) 中的 O，它表明您可以在不更改源代码的情况下更改其行为。因为如果您想对您的对象进行新/删除/更改操作，您只需添加/删除/更改此对象的访问者，而不是对象本身。
【讨论】：