refactoring - Duck 类型作为反射的语法糖 : Good or bad idea?

Question

我最近一直在想，在 Java 和 C# 等语言中，将“鸭子类型(duck typing)”类型作为方法参数类型包含在内是否是一种很好的语法糖形式？这将如下所示:

void myFunction(duck foo) {
   foo.doStuff();
}

这可以是通过反射调用 doStuff() 的语法糖，也可以以不同的方式实现。 Foo 可以是任何类型。如果 foo 没有 doStuff() 方法，这将引发运行时异常。关键是，当您需要它们时，即大多数时候，您将获得更严格的预先指定的接口(interface)范例(性能、错误检查)的好处。同时，您将拥有一个简单、干净的后门来避免打字，这将允许您干净地进行初始设计中未预见到的更改，而无需进行大规模重构。此外，它可能会 100% 向后兼容，并与现有的语言结构完美结合。我认为这可能有助于减少过度设计的以防万一的编程风格，这种风格会导致困惑、困惑的 API。您认为这样的事情在 C# 和 Java 等静态 OO 语言中是好事还是坏事？

Answer 1

dynamic关键字支持这些确切的语义并将在 C# 4.0 中。

不过，这不仅仅是为了反射(reflection)。它是 dynamic dispatch 的实现只有在没有其他机制可用时才使用反射。

This question也有很多很好的信息。