My new toy is the Ruby language (I know, toys are a serious thing). I'm experimenting a bit, trying to see why all the fuss. Until now I like what I see. It's my first experience with a dynamic language and I feel quite comfortable with it. What I like most until now is
duck typing, and no, it's not a typo, I really mean duck, the animal.
This comes from the more pure concept of interface in which you consider that two different objects have the same interface if they respond to the same messages, to the same way of interacting, of talking to them.
The duck analogy comes from saying that if something looks like a duck, then it's a duck. So in Ruby you don't need to define interfaces the way C#/Java does. Interfaces exist but you don't define them, they are already there, conceptually.
The biggest advantage I see about this is that the effort needed to assure that your design is low coupled is greatly reduced. Any object can be substituted by any other that implements the required methods without extra work. This dramatically improves your efficiency when making changes and evolving your design and testing gets easier.
Let's compare a bit C# and Ruby interfaces:
interface Cuackable
{
void Cuack();
}
class ADuck : Cuackable
{
public void Cuack()
{
//cuack the ADuck way
}
public void Swim()
{
//swim the ADuck way
}
}
class BDuck : Cuackable
{
public void Cuack()
{
//cuack the BDuck way
}
public void Swim()
{
//swim the BDuck way
}
}
So If you need the
Cuackable interface from your client code, you declare a variable or parameter that will eventually hold an
ADuck or
BDuck implementation.
The compiler knows you can use
ADuck or
BDuck because they declare they implement the needed interface.
You know you can use
ADuck or
BDuck because they implement the method signatures that you need. So there's a mismatch between the way you think of the interface and the way the compiler does (Ruby doesn't have this mismatch, we'll see this later).
What happens if now you realize that
Swim should be part of another interface? Well then you'll have to define a new
Swimable interface and define
Swim as it's only member. You'll also need to implement that interface in each of the classes that implement the method and you'll also need to make the clients use that interface.
interface Cuackable
{
void Cuack();
}
interface Swimable
{
void Swim();
}
class ADuck : Cuackable, Swimable
{
public void Cuack()
{
//cuack the ADuck way
}
public void Swim()
{
//swim the ADuck way
}
}
class BDuck : Cuackable, Swimable
{
public void Cuack()
{
//cuack the BDuck way
}
public void Swim()
{
//swim the BDuck way
}
}
Now imagine that you have a third client method that requires to use both
Cuack and
Swim. In that case you'd have to pass the same object in two parameters to the client method:
void ClientMethod(Cuackable cuackable, Swimable swimable)
{
//code
cuackable.Cuack();
//...
swimable.Swim();
//more code
}
//later you could call ClientMethod with the same object if you think that's correct...
aDuck = new ADuck();
ClientMethod(aDuck, aDuck)
//or with different objects if that's what's intended...
ClientMethod(new ADuck(), new BDuck());
Another alternative for the first example, although not the same, is creating another new interface that joins
Cuackable and
Swimable, a good name would be, ermmm...
Duck. Then now you'd be implementing three different interfaces, all describing the different ways your client code can see your objects.
This grows exponentially being the number of possible interfaces 2^n - 1, where n is the number of public methods. Of course your clients see them only in the subset of 2^n - 1 that is useful to them, but this will be still a big number in non trivial systems, always assuming that you really believe in object polymorphism and the
interface segregation principle which encourages having small interfaces.
As you can see, such a big number of interfaces is impractical to handle in strongly typed languages so we usually change the way we design to cope with this programming infrastructure problem and we start violating principles of good design. The most common solution to this is having huge interfaces with clients that, of course, just use a subset of them. This is, among other problems, a manteinance nightmare. But a smaller nightmare than the more correct alternative of having one interface for each method.
Ruby's duck typing
Let's see the previous code in it's Ruby version:
class ADuck
def cuack
#cuack the ADuck way
end
def swim
#swim the ADuck way
end
end
class BDuck
def cuack
#cuack the BDuck way
end
def swim
#swim the BDuck way
end
end
def client_method(can_cuack_and_swim)
#code
can_cuack_and_swim.cuack
#...
can_cuack_and_swim.swim
#more code
end
client_method(ADuck.new)
#or you can split it in two like the previous C# example
def client_method(can_cuack, can_swim)
#code
can_cuack.cuack
#...
can_swim.swim
#more code
end
client_method(ADuck.new, BDuck.new)
As you can see, we don't define interfaces, they are implicitly there because as we said earlier, interfaces are defined by the clients.
client_method just asks that the object that is passed as a parameter implements the required method. If you create a new class that implements those required methods, then you implement
client_method required interface, your client sees a duck because your object behaves the way it expects, like a duck, no more extra work for creating and mantaining your classes interfaces. That's simplicity and programmer friendliness, from there you get easier abstraction, free low coupling and the resultant increase in quality and productivity in the right way.
