I’m new to Ruby - actually new to dynamically typed languages in
general. I’m from more of a C++ and C# (strongly-typed and
statically-typed) background.
One thing I’m trying to wrap my brain around is the lack of explicit
interface definitions. In C# we use interfaces so that client code can
program against an abstract interface, and then you can give that client
any concrete implementation of that interface as needed. Interfaces
provide a level of abstraction/indirection that increase reusability and
testability.
Now, in Ruby, I like the “walk like a duck” approach. Actually, it’s
similar to C++ templates which are very powerful.
But there are two things that I worry about as I forge ahead in my new
Ruby lifestyle:
In C# I can write code that can query an object for the interfaces it
implements to find out what I can do with it. (Rarely used but
sometimes a lifesaver). In Ruby I guess I have to use .methods to find
out what methods it implements?
In C# I can insure that a function is given an object that implements
a certain interface. If I don’t, it’s a compile-time error and I know
it before I ship it. In Ruby, I won’t know if I accidentally pass in
the wrong object until runtime. I might not catch it before I ship the
code.
In C# I can write code that can query an object for the interfaces it
implements to find out what I can do with it. (Rarely used but
sometimes a lifesaver). In Ruby I guess I have to use .methods to find
out what methods it implements?
You can use Mixins (Modules) and the query the mixins.
So if your object includes Comparable or Enumerable, you can be sure
it has the methods of these mixins
In C# I can insure that a function is given an object that implements
a certain interface. If I don’t, it’s a compile-time error and I know
it before I ship it. In Ruby, I won’t know if I accidentally pass in
the wrong object until runtime. I might not catch it before I ship the
code.
using respond_to? is usually the way you can do this.
In C# I can write code that can query an object for the
interfaces it
implements to find out what I can do with it. (Rarely used but
sometimes a lifesaver). In Ruby I guess I have to use .methods to
find
out what methods it implements?
We generally use respond_to?() for this, but I must stress be REALLY,
REALLY sure before you check. Ruby is VERY dynamic. The object may
not have the method you ask for until you call it. This is totally
normal and okay.
I’ve actually seen people check, so they can throw an Exception if
it’s not there. Ruby was going to do that anyway.
Can anyone provide some enlightenment?
Write proper unit tests so you catch it before it goes out the door
This is first class advice right here. This should catch type issues
and much, much more. The better you get at it, the more you will
structure your code for testing (using small methods, for example).
That just reduces type issues even further.
And you gain so much freedom and power. I promise, when it clicks,
you’ll never go back. “Free your mind…”
One thing I’m trying to wrap my brain around is the lack of explicit
interface definitions. In C# we use interfaces so that client code can
program against an abstract interface, and then you can give that client
any concrete implementation of that interface as needed. Interfaces
provide a level of abstraction/indirection that increase reusability and
testability.
As others have already noted in Ruby we generally do the simplest thing
that will work – which is just calling methods in most cases. Where
that doesn’t work we can still check for the presence of an included
Module or methods. Or actually rescue the NoMethodError ourselves and
try something else. There’s a lot of ways.
Anyway – the reason for why I’m really posting is that I have played
around with using unit tests for doing interfaces / contracts in Ruby.
This can provide you with argument checking and similar things, but it
is a toy. You can find this at http://ruby-contract.rubyforge.org/
It might also give you a general idea of how much power you can get out
of Ruby’s dynamic nature.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
