views:

169

answers:

3

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?

+2  A: 

Defining an interface is a kind of in-code documentation. With an interface you declare explicitly what you expect from the class to satisfy your needs.

PS: groovy is not my language, so I actually don't know whether it's possible to define interfaces there at all.

Vlad
+4  A: 

I'm not familiar with groovy, but in general, no, you don't need to define interfaces in loosely typed languages.

  1. You would be repeating yourself, if you need to change a methods signature, then you need to do it in two places, not one.

  2. Although interfaces do have some use as documentation, in a loosely typed language, most coders will not expect an interface, and therefore will not go searching for an interface if they need documentation.

  3. Most dynamic languages have good IDE's available for them, with method completion, which further diminishes the need for a separate interface.

  4. Methods can be bound and unbound in dynamic languages. Therefore, you can, and probably will, end up with objects that do not adhere to the interface. Having a separate interface could end up confusing people reading your code.

longshot
@longshot what IDE/language do you use with good method completion? I use Netbeans with Ruby, and more often than not it doesn't know what methods are available, and is just completing them from a global namespace.
Yar
@yar for example RubyMine
Sergey Mirvoda
Squeak smalltalk has good method completion, and method browser. AllegroCL has good autocompletion for Common Lisp. WingIDE has good autocompletion for Python, as long as it knows what type you are referencing. XCode has good completion for ObjC, with the same caveat that it needs to know the type you are sending a message to.
longshot
All good points. Thank you.
Martin Smith
@longshot and @Sergey Mirvoda, thanks for that. Objective-C is my new problem, so I hope that XCode does that.
Yar
+7  A: 

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.

Yar
Thanks very much. A very good answer. I won't be using them!
Martin Smith
@Martin, thank you, I've appended my answer a bit to explain better.
Yar