Design patterns 接见者模式

当我读到访客模式时，它说

允许在运行时将一个或多个操作应用于一组对象，从而将操作与对象结构分离

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

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

我不同意

将逻辑放在对象中而不是放在访问者中并不总是可能或可取的。例如，作为“域”层一部分的持久实体（用户或订单）不一定有权（或不应该有权）访问执行操作所需的服务（作为“服务”层的一部分）：为订单开票或提升用户

而且，仅仅因为现在只有一个访问者并不意味着其他访问者以后不会出现

该模式的目标是解耦。通过将操作放在访问对象本身中，您就不再需要解耦了

---

通过解耦，您还可以创建一个可重用的API。使用您的类的开发人员很可能无法修改它们，因为他/她根本没有源代码，因此无法更改。然而，它必须能够根据对象的实际具体类做一些不同的事情。因此出现了访问者模式。

您对访问者模式的描述说明了这一切：

将操作与对象结构分离

在一个完全解耦的世界中，您将拥有保存数据的对象和对数据进行操作的对象。访问者模式的目标是将这些功能解耦。这可能不是一个你经常明确看到的模式，但是你在任何地方都会看到潜在的原则

---

通过解耦操作，您可以使用SOLID（）中的O，它表示您可以在不更改源代码的情况下更改其行为。因为如果你想对你的对象进行新的/删除/更改操作，你只需添加/删除/更改这个对象的访问者，而不是对象本身。

实际上你根本不需要使用这个模式或任何其他模式。如果您正在使用模式，是因为您正在根据上下文进行设计选择

模式文档的几个项目旨在帮助您做出关于使用或不使用模式的明智决策。特别是，请检查以下部分：

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

如果您处于从对象结构解耦操作中获益的环境中，可能是因为将来会有新的操作应用于这些对象，该模式将改进您的设计。如果您所处的环境是一个生命周期有限的小程序，那么该模式可能是一种开销

---

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

是的，您是正确的。事实上，一般来说，当你有一个只有一个子类的基类时，那么有些东西是可疑的。这对于访问者来说尤其如此。访问者很复杂，而且很难调试。在需要之前不要应用模式。我可以在我家的前门装一扇旋转门，但这比普通门麻烦多了。旋转门有好处，如果有一个大温差内外，有很多人来来去去。首先应用的设计模式是KISS aka YAGNI。