From: Mathieu Bouchard <matju@...>
Date: 2005-01-25T15:57:32+09:00
Subject: Re: "Duck Typing" or "No need for abstract classes"


On Tue, 25 Jan 2005, Edgardo Hames wrote:

> I don't need a Protocol class, the network client should just call the
> methods of the protocol and duck typing should do all the magic. Am I
> right? Am I coming a little closer to walking the Ruby Way?

Ruby allows you to play in the swamp, but it doesn't mean it's better to
play in the swamp: rather see it as an opportunity to build your own raft,
hopefully better than the one-size-fits-all raft provided with your
standard static-language.

If you want to automate and refactor (DRY/OAOO) your unit-tests to the
point that a set of unit-tests is shared among all modules-or-classes that
implement the same protocol, then it's better to encode a hint in your
program. That hint is to inherit from a dummy module-or-class.

Furthermore, once you have done that, you have also automated the process
of adding helper-methods to all modules-or-classes that implement the same
functionality. Think about how you can add methods to Enumerable and
Comparable.

A small aside regarding Ruby's peculiar multiple-inheritance system: I'd
rather define a protocol using a non-class module than with a class,
because then a same class can implement several protocols without
conflict, as a class can inherit from any number of non-class modules, but
only from one class, and a non-class module cannot inherit from a class at
all.

Those are pragmatic techniques completely consistent with the basic
principles of pragprog/xp/agile, but for some reason, many among those
communities have preferred to take a more, er, romantic path.

Duct-taping as a design philosophy is an obfuscation technique.

More Canadian Content:

  http://images.amazon.com/images/P/B00008R9KR.01.LZZZZZZZ.jpg

_____________________________________________________________________
Mathieu Bouchard -=- Montr�al QC Canada -=- http://artengine.ca/matju