On Dec 3, 2006, at 5:02 AM, Pat Maddox wrote:

> On 12/3/06, Robert Dober <robert.dober / gmail.com> wrote:
>> On 12/3/06, James Edward Gray II <james / grayproductions.net> wrote:
>> >
>> > On Dec 2, 2006, at 5:15 PM, Daniel Berger wrote:
>> >
>> > > Perhaps my whole approach is wrong.  What is the proper way to  
>> achieve
>> > > what I'm after (without resorting to making Bar a module)?
>> >
>> > This works, but is probably poor style:
>>
>>
>> Which would follow from one of the basic rules of OOP, if memory  
>> serves:
>> A Class does not know anything about its subclasses, be it  
>> abstract or not.
>> OP I suggest that you rethink your design, AFAIK that would not be  
>> very
>> flexible concerning new subclasses right?
>
> Of course every rule has exceptions.  For example, in Beck's
> Test-Driven Development, after a bit of refactoring you end up with
> something like (converted to Ruby :)
>
> class Money
>  class << self
>    def dollar(amount)
>      Dollar.new amount
>    end
>
>    def franc(amount)
>      Franc.new amount
>    end
>  end
> end
>
> The reasoning behind this is that since the clients only go through
> Money, you can change the underlying inheritance structure without
> breaking anything.

In Ruby you can even handle this dynamically.  Using the inherited()  
hook, we could collect a list of available subclasses.  That list  
could then be used to check requested types and instantiate them.

James Edward Gray II