鸭子类型作为反射的语法糖：好还是坏主意？
我最近一直在想，在 Java 和 C# 等语言中包含“duck”类型作为方法参数类型是否是一种很好的语法糖形式？ 这看起来如下：
void myFunction(duck foo) {
foo.doStuff();
}
这可能是通过反射调用 doStuff() 的语法糖，或者可以以不同的方式实现。 Foo 可以是任何类型。 如果 foo 没有 doStuff() 方法，则会抛出运行时异常。 关键是，当您需要时（即大多数时间），您将获得更严格的预先指定的接口范例（性能、错误检查）的好处。 同时，您将拥有一个简单、干净的后门来鸭子打字，这将允许您干净地进行初始设计中未预见到的更改，而无需进行大规模重构。 此外，它可能 100% 向后兼容，并与现有语言结构完美契合。 我认为这可能有助于减少过度设计的以防万一编程风格，这种风格会导致 API 的混乱和混乱。 您认为这样的事情对于 C# 和 Java 等静态 OO 语言来说是好事还是坏事？
I've been thinking lately, would it be a good form of syntactic sugar in languages like Java and C#, to include a "duck" type as a method parameter type? This would look as follows:
void myFunction(duck foo) {
foo.doStuff();
}
This could be syntactic sugar for invoking doStuff() via reflection, or it could be implemented differently. Foo could be any type. If foo does not have a doStuff() method, this would throw a runtime exception. The point is that you would have the benefits of the more rigid pre-specified interface paradigm (performance, error checking) when you want them, i.e. most of the time. At the same time, you'd have a simple, clean-looking backdoor to duck typing, which would allow you to cleanly make changes not foreseen in the initial design without massive refactoring. Furthermore, it would likely be 100% backwards compatible and mesh cleanly with existing language constructs. I think this might help cut down on the overengineered just-in-case programming style that leads to confusing, cluttered APIs. Do you believe that something like this would be a good or bad thing in static OO languages like C# and Java?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
dynamic关键字支持这些确切的语义，并将出现在 C# 4.0 中。但这不仅仅是为了反思。 它是动态调度的实现，仅在没有其他机制可用时才使用反射。
这个问题也有很多好信息。
The
dynamickeyword supports these exact semantics and will be in C# 4.0.It is not just for reflection, though. It is an implementation of dynamic dispatch which uses reflection only if no other mechanism is available.
This question also has lots of good information.
实际上，这非常类似于 C#4 中的“动态”类型。
Actually, that's very much like the "dynamic" type that will be part of C#4.
我的简短回答是“是的，Duck Typing 在 OO 语言中是一个有用的工具。C# 团队同意，并将其放入 C# 4.0”
长答案：
Duck Typing 有其优点和缺点......有一个很多人完全放弃它，但我会告诉你：使用鸭子类型有一些非常令人信服的理由来解决在任何其他情况下都无法很好解决的问题。
请参阅我关于界面的帖子，该界面采用字典而不是 IDictionary，其中 Duck Typing 可以挽救这一天：
http://www.houseofbilz.com/archive/2008/09/22/why-you-really-need-to -think-about-your-interfaces.aspx
C# 自 1.0 以来内置了一些鸭子类型！ 以 foreach 关键字为例。 一个常见的误解是，您的类型需要是 IEnumerable 才能在 foreach 循环中使用对象。 事实上，事实证明这不是真的。 您只需要实现 GetEnumerator() ，并且不需要实现该接口（不过，这是一种很好的形式）。 这是鸭子打字。
My short answer is "Yes, Duck Typing is something that would be a useful tool in OO languages. The C# team agrees, and is putting it into C# 4.0"
Long answer:
Duck Typing has its pros and cons... there are a lot of people who swear it off completely, but I'll tell you what: There are some very compelling reasons for using Duck Typing for things that can't be solved well in any other case.
See my post on an interface that took a Dictionary instead of an IDictionary where Duck Typing would have saved the day:
http://www.houseofbilz.com/archive/2008/09/22/why-you-really-need-to-think-about-your-interfaces.aspx
C# has SOME duck typing built in since 1.0! Take the foreach keyword, for instance. It is a common misconception that your type needs to be IEnumerable in order to use an object in a foreach loop. It turns out, in fact, that this is NOT true. You only need to implement GetEnumerator() and implementing the interface is not necessary (it IS good form, though). This is Duck Typing.