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