oop - 在 OOP 中，拥有更多类和更少方法而不是更少类和更多方法是否一定是有利的？

Question

我一直在研究设计模式，并且遇到了访问者模式。这对我来说真的很奇怪。似乎它的唯一目的是防止层次结构中的原始类需要更改，即使向它们添加了新的职责。只需将这些职责委托给抽象访问者类（或接口）的实现，并有效地进行双重调度以调用正确访问者的操作函数并传入正确的动态类型，就可以实现这一点。

我研究了各种其他问题，讨论何时以及为什么使用访问者模式，我所遇到的只是在 OOP 中，预计你的类数量会增长，而不是每个类的方法数量，这访客模式专门研究。

然而，这是真的吗？对我来说，这听起来像是对 OOP 的过度简化。作为参考，这个答案来自这里

我还在这里阅读了另一个（松散）相关的问题，其答案暗示您应该只在有意义的地方创建更多的类和单独的职责。组织你的代码真的有意义吗，这样一个类的“责任”仅仅由一个操作定义，而不管被操作的类型是什么（即访问者负责执行每个相关类型的操作） ，或者将责任定义为可以在单个类型上完成的一组操作是否更有意义（将这些责任委托给类型本身）？

如果目标仅仅是减少每个类中的代码行数，为什么这是一个合理的目标？单独的行数对封装、模块化、代码组织或一般良好的 OOP 实践没有任何直接影响，对吧？

编辑： 我现在明白不存在服务于 OOP 的模式，而且我现在明白在某些情况下访问者模式是最好的解决方案。话虽如此，当与 OOP 一起使用时，它是否会促进不太明智的类层次结构？

标签： oopsingle-responsibility-principlevisitor-pattern

Answer 1

我认为您可能误解了访问者模式和一般模式的作用以及我们有时使用它们的原因。

这不是因为一些面向对象的东西，一些抽象的概念或一些隐藏的事实。情况恰恰相反。您应该以适当的面向对象的方式对问题进行建模，使用具有行为、隐藏状态的对象，等等。简而言之，这就是OO。你不应该出去寻找在你的代码中随机应用的模式，事实上这本身就是一个反模式:)

现在，有些人注意到，对于某些小问题，我们大多数人都倾向于提出类似的解决方案。这些很有趣，不是因为这些解决方案非常具有开创性，或者它们本身就很有价值，而是因为它只是为我们节省了一些时间和脑力，而不是一遍又一遍地解决这些问题。这些是模式。

回到您的问题：如果您不太了解访问者模式的作用或原因，或者如何/为什么使用它，请不要担心。如果您遇到需要它的问题，您会注意到的！在这种情况下，没有其他方法可以正常工作，您基本上必须使用它。在所有其他情况下，您不应该使用它！

总结：不，我们不使用访问者模式是因为一些面向对象的事情。减少线条本身并不是一个合法的目标。是的，单独的行数不会影响封装、模块化等。