访问者模式

Question

当我阅读关于访问者模式的内容时，它说：

允许在运行时将一个或多个操作应用于一组对象，将操作与对象结构解耦。

如果我的假设是正确的，我们将定义一个抽象访问者，其中包含用于处理每个对象的方法。然后具体访问者将实现这些方法。通过这种方式，我们将对象处理逻辑从对象类分离到访问者实现中。

我的疑问是，如果我们只有一个访问者实现，我们真的需要使用这个模式吗？难道我们不能直接将实现放在每个对象类中并直接调用它吗？如果我漏掉了什么，请纠正我。

- Jomy George

---

是的，你说得对。事实上，通常情况下，当你有一个只有一个子类的基类时，就会让人感到可疑。特别是在访问者模式中更是如此。 - Ami Tavory

访问者模式很复杂，调试起来更加困难。在需要时再应用设计模式。我可以在房子的前门口安装旋转门，但这会比普通门麻烦得多。如果内外温差很大，而且有很多人进出，那么旋转门就有好处了。首先应用的设计模式是KISS（保持简单原则）或YAGNI（你不需要它）。 - Fuhrmanator

Answer 1

实际上，您并不真正需要使用这种模式或任何其他模式。如果您正在使用模式，则是基于您的上下文进行设计选择。

模式文档的几个部分旨在帮助您对使用模式做出明智决策。特别是，请查看以下部分：

- 意图：模式背后的目标和使用它的原因的描述。 - 动机（作用力）：由问题和可以使用此模式的上下文组成的场景。 - 适用性：适用此模式的情况；模式的上下文。 - 后果：使用该模式引起的结果、副作用和权衡的描述。

如果您处于从对象结构中解耦操作受益的上下文中，可能是因为将来会有新的操作要应用于这些对象，则该模式将改善您的设计。如果您处于具有有限生命周期的小型程序的上下文中，则该模式可能会增加负担。

因此，请再次阅读模式文档，检查您的软件上下文，并对使用它或不使用它做出明智的决策。

- JuanZe

Answer 2

我的观点不同。

并不总是可能或值得将逻辑放在对象内部而不是放在访问者内部。例如，持久化实体（用户或订单）是“领域”层的一部分，它并不一定具有（或不应该具有）执行操作所必需的服务（“服务”层的一部分）的访问权限：账单订单或提升用户等。

此外，现在只有一个访问者，并不意味着以后不会出现其他访问者。

该模式的目标是解耦。通过将操作放在被访问的对象本身中，您不再具有解耦效果。

通过解耦，您还可以创建可重用的API。使用您的类的开发人员很可能无法修改它们，因为他/她根本没有源代码，因此无法更改它。然而，它必须能够根据对象的实际具体类别执行不同的操作，这就是访问者模式。

- JB Nizet

Answer 3

你对访问者模式的描述已经说明了一切：

将操作与对象结构解耦

在一个良好解耦的世界中，你会有持有数据的对象和操作数据的对象。访问者模式的目标是解耦它们。这可能不是一个你经常明确看到的模式，但你会在各个地方看到其基本原则。

通过解耦操作，你使用了SOLID中的O（开闭原则），该原则指出你可以在不改变源代码的情况下更改其行为。因为如果你想要在对象上添加/删除/更改操作，你只需要添加/删除/更改该对象的访问者而不是对象本身。

- sanderarts