我应该用Duck Typed语言定义接口吗？ [英] Should I define interfaces in Duck Typed languages?
问题描述
如果我要用静态类型化语言编写同一个应用程序那么我需要定义一些接口。显然，由于在Groovy中输入了鸭子，他们实际上并不需要。目前，我认为将它们定义为需要在各种对象中实现的方法的文档是有意义的。我是否错过了这个观点？
我最近一直在阅读关于SO的文章（我找不到现在链接，但它是其中一个为什么动态语言很好？的帖子，以及由S. Lott提供的很多评论的一个重要答案），答案是：
<你可以。特别是在Groovy中，您可以在Java或Groovy中定义接口并实现它们。但是，使用鸭子键入（Groovy允许，但也允许显式类型），许多人会说为什么打扰？源代码是它自己的文档，接口在源代码中，使用源代码等。
个人而言，这让我发疯 - 我喜欢编译时（或真正的开发时间）检查Java给我，但这是另一场辩论。如果您使用的是Groovy，那是因为您想要编写出色的简洁明了的代码来源于鸭子输入。在那种情况下，除非必要，否则应避免使用接口。
它们在哪里是必需的？程序的各个部分之间，以及程序的公共API（尽管它们也可以是抽象类）。否则，我会说你应该尽量避免使用鸭型语言。这迫使你在类上编写文档，或者编写清晰的代码，使其完全相同。
我认为这是一种糟糕的做法，但是这是动态语言范式转变的一部分。我认为，如果你避免将界面与实施分开，你就会明白它背后的原因。我仍然没有，尽管它与重复代码（保持DRY）有很大关系。
编辑：计算机:)不将界面与实施分开的主要原因之一是，您不必依赖类型。如您所知，在鸭子打字中，我不在乎它是否是 Vehicle 界面的实施者（例如）。我只关心它是否有带2个参数的 go 方法。因此，使用接口越多，您在Groovy中编写Java越多（您可以用任何语言编写Fortran）。应该避免这种情况，因为新的语言可以为你提供新东西。
I'm just about to write my first application in a duck typed language (Groovy).
If I was to write the same application in a static typed language then I would need to define some interfaces. Obviously because of the duck typing in Groovy they are not actually required. At the moment I am thinking that it might make sense to define them anyway as documentation of the methods that need to be implemented in the various objects. Am I missing the point?
I've been reading on this recently here on SO (and I can't find the link right now, but it's one of those "why are dynamic languages good?" posts, and a big answer by S. Lott with many comments), and the answer is:
You could. In Groovy especially, you can define interfaces in Java or Groovy and implement them. However, with duck-typing (which Groovy allows but also allows explicit types) many people would say "why bother?" The source is it's own documentation, the interface is in the source, "use the source" etc.
Personally, this drives me mad -- I love the compile-time (or really, dev-time) checks Java gives me, but that's another debate. If you're using Groovy, it's because you want to write that brilliantly concise and clear code that comes from duck-typing. In that case, interfaces are to be avoided except where necessary.
Where are they necessary? Between parts of a program, and in the Public API for a program (though they can be abstract classes, too). Otherwise, I would say that you should try to avoid them in duck-typed languages. This forces you to write the docs on the classes, or write code that is so clear that it's the same thing.
I think this is terrible practice, HOWEVER this is part of the paradigm shift towards dynamic languages. And I think that if you avoid separating interface from implementation enough, you'll understand the 'why' behind it. I still do not, though it has a lot to do with not repeating code (keeping DRY).
Edit: Got some clarity away from the computer :) One of the main reasons NOT to separate interface from implementation is so that you move away from a dependence on types. In duck-typing, as you know, I don't care if it's an implementer of the Vehicle interface (for instance). I only care if it has a go method with 2 params. So the more you work with interfaces, the more you are writing Java in Groovy ("you can write Fortran in any language"). This should be avoided, as new languages open you up to new stuff.
这篇关于我应该用Duck Typed语言定义接口吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
