On Saturday, July 17, 2010 08:21:10 pm James O’Brien wrote:
I have found the concept of an interface invaluable in my Java programming
and wondered if there were an equivalent concept in Ruby?
Yes and no.
Yes, there is certainly a concept of an “interface” – this is an
concept that really applies to all languages. But no, it’s not built-in
More specifically, the Java concept of an interface is only really
because Java is statically typed.
as a thought-experiment I
propose Java without interfaces would be worse
Take some common examples from the Java standard library – Map would be
good one. Now, Interfaces are especially cool because I don’t have to
that an object actually uses a hash internally – it might use btrees,
might use something entirely different – all I care about is that it
to behave roughly like a Map is supposed to, and it presents get(),
So, for example, I could declare an object to have a type like this:
Map<String, List> files;
You could conceivably store these files as a HashMap, mapping filenames
lists of lines in the file. Of course, the cool part about interfaces is
it could also be a thin wrapper around a real filesystem (so you don’t
slurp them all at once), or it could talk to a database, or any number
But on closer examination, was that actually the right abstraction? What
you doing with those files that you care that they’re lists of strings,
not one giant string or an IO stream of some sort?
In the statically-typed world of Java, it makes sense that you would
your interfaces up front like this, because everything needs to have a
and types are all defined and planned out ahead of time. It’s not just
it’d be horrible design to do this:
It’s that it wouldn’t work – in order to call any methods on it, you
need to typecast it to something you know how to interact with.
In Ruby, things are a bit different. We have this concept called “duck
– if it quacks like a duck, it may as well be a duck, who cares what it
actually is? If it isn’t a duck, it should break our unit tests, which
think where it ties in to your comments here:
I’m well versed in
the benefits of test driven code and documentation but we have this in Java
Since Ruby is dynamically-typed (and duck-typed), I don’t specify the
interface I need – at least, not directly. I specify it by how I
the object in question:
Now, there’s still an implicit interface – in this case, “Something
responds to , and returns something which puts knows how to turn into
string.” But I don’t have to spell that out in code – again, either it
(which it does, 99% of the time) or it causes a runtime issue, which is
unit tests are for.
That’s the crucial difference – in Ruby, I can just blindly fire a
call on an object, without knowing what type it is. In Java, I can only
methods on the object when I know it’s of a type that supports those
and which type it is.
So, in Java, interfaces actually let you do things you wouldn’t
able to do. In Ruby, I don’t really see what purpose interfaces would
what they would enable me to do. I much prefer the implicit duck-typing
interfaces. If it’s a situation where I need an explicit interface as
documentation, I think documentation works well enough.