我想知道多重分派(dispatch)的概念(即内置支持，就好像虚拟方法的动态分派(dispatch)也扩展到方法的参数一样)是否应该包含在对象中面向性能的语言，如果它对性能的影响可以忽略不计。
问题
考虑以下场景:我有一个(不一定是扁平的)包含动物类型的类层次结构。在代码中的不同位置，我想对动物对象执行一些操作。我不关心，也无法控制如何获取此对象引用。我可能会通过遍历动物列表来遇到它，或者它可能会作为方法的参数之一提供给我。我想要执行的操作应该根据给定动物的运行时类型进行专门化。此类操作的示例包括:
- 为动物构建 View 模型，以便在 GUI 中呈现它。
- 构造一个代表此类动物的数据对象(稍后存储到数据库中)。
- 给动物喂一些食物，但根据动物的类型给予不同种类的食物(什么对它来说更健康)
所有这些示例都对动物对象的公共(public) API 进行操作，但它们所做的不是动物自己的事情，因此不能放入动物本身。
解决方案
一个“解决方案”是执行类型检查。但这种方法很容易出错，并且使用反射特性，(在我看来)这几乎总是糟糕设计的表现。类型应该只是一个编译时概念。
另一个解决方案是“滥用”(某种程度上)访问者模式来模仿双重调度。但这需要我改变我的动物来接受访客。
我确信还有其他方法。另外，还需要解决扩展问题:如果有新的动物类型加入，需要适配多少个代码位置，如何可靠地找到它们？
问题
那么，鉴于这些要求，多重分派(dispatch)不应该成为任何设计良好的面向对象语言的组成部分吗？
使外部(不仅仅是内部)操作依赖于给定对象的动态类型不是很自然吗？
最诚挚的问候!
最佳答案
您建议基于方法名称/签名与运行时实际参数类型相结合的动态调度。我觉得你疯了。
So, in the light of these requirements, shouldn't multiple dispatch be an integral part of any well-designed object-oriented language?
对于某些问题，您设想的那种调度策略的可用性会简化编码，但对于将这种调度构建到任何给定语言中来说，这是一个很弱的论据，更不用说每种 OO 语言了。
Isn't it natural to make external (not just internal) actions dependent on the dynamic type of a given object?
也许吧，但并非所有看似“自然”的事情实际上都是好主意。例如，衣服并不自然，但看看如果你尝试在公共(public)场合不穿衣服(无论如何，除了伯克利以外的地方)会发生什么。
某些语言已经具有基于参数类型的静态调度，更传统的称为“重载”。另一方面，如果要考虑多个参数，基于参数类型的动态调度就会变得一团糟，而且速度会很慢。当今流行的面向对象语言允许您在需要的地方执行双重调度，而无需在绝大多数您不需要的地方支持它的开销。
此外，尽管实现双重调度确实会带来由于单独组件之间的紧密耦合而产生的维护问题，但有一些编码策略可以帮助保持这种情况的可管理性。无论如何，目前还不清楚在给定语言中内置基于参数的多重分派(dispatch)实际上能在多大程度上帮助解决这个问题。
关于oop - 多次调度 : A conceptual necessity?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30466001/