[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Interfaces in Ruby
From:       Paul Brannan <pbrannan () atdesk ! com>
Date:       2002-10-17 14:55:46
[Download RAW message or body]

On Thu, Oct 17, 2002 at 11:19:04AM +0900, Chris Gehlker wrote:
> > The goals behind an interface or abstract class are:
> >   1) Be able to write a function that can take as a parameter any 
> >      object that inherits from the abstract class (generic
> >      programming).
> 
> I don't agree that an interface, in the Java sense, and an abstract 
> class, in the Java/C++ sense are synonymous or that an interface has 
> necessary relationship to generic programming. Generic programming came 
> out of C++, which has no notion of interface.

I think I was mistaken to call this "generic programming," which is
similar but different.  Must have been too much sugar after lunch. :)
I think the correct word is "polymorphism."

http://www.c2.com/cgi/wiki?PolymorphismExample

> I believe the most common uses of the abstract class are:
>
> 1) To provide code clarity and to avoid code duplication

I can agree that abstract classes can help provide clarity.  I don't see
how they avoid code duplication, since pure abstract base classes are
not supposed to have any implementation.

> 2) To provide a way of referencing an object who's type is not 
> determined until run time, for example, the elements of a display list 
> in a drawing program.

This also falls under polymorphism.

> There are also:
> 3) Idiosyncratic but very clever uses as, for example, in the STL, 
> where it is somewhat obscured by all the template stuff, and in GNUStep 
> where it isn't.
> 
> Motivation 2 disappears in dynamic langaguages. 1 and 3 remain.

I can't think of a case in Ruby where #3 would apply.

> There is no need to enforce the use of the factory method. What needs 
> to be enforced is that the program cannot instantiate an instance of 
> the cluster base class. This corresponds directly to the C++ case where 
> their is no enforcement of a restriction on directly constructing a 
> derived concrete class but there is enforcement of the "no 
> instantiation of virtual classes" rule.

In Ruby, if the base class has implementation, I would almost certainly
throw it into a Module, because you cannot instantiate a Module.  If it
has no implementation (the "Toy" abstract base class in the wiki link
above), then I generally remove it completely.

What would keep you from turning your cluster base class into a Module,
and using it as a mixin?

Paul


[prev in list] [next in list] [prev in thread] [next in thread]