From: dblack@... Date: 2003-02-11T23:26:50+09:00 Subject: Re: inheriting from base classes Hi -- On Tue, 11 Feb 2003, Pete McBreen wrote: > The normal test for subclassing is to see if the question "Is a Y is a > kind of X?" is true for the proposed subclass, when you talk about the > concepts that the subclass represents. I have a Ruby-specific question about this, which I ask with a bit of trepidation since I know that OO principles at this level of abstraction are generally not language-specific.... In Ruby, it seems to me that the module mechanism does a lot to reduce the importance of the class hierarchy tree. Or, to relate it to your point, modules add adjectives to the mix. So "Is a Y a kind of X?" might come out as, "Is a Y a Z-able X?" And the answer to this kind of question might (?) more often be "Yes." > Is a ClassRoster a kind of Array? Probably false. From the name I'd > guess that ClassRoster represents the group of people attending the > class, and alternate implementations not based on Array are probably > just as useful. But then there's the question: if a ClassRoster is essentially an ordered list of Student objects, and that list is going to be added to, sorted, subtracted from, mapped over, etc. etc.... what is the disadvantage to having it subclass Array (rather than sort of shadow Array via instance variables and rewriting of methods that Array already has)? I'm willing to believe there are disadvantages, but I'm not succeeding in picturing an actual scenario where it would play out badly. And, again, there's the presence of modules. One might say: a ClassRoster is a Gradeable Array, or some such. > Are AssignmentValues a kind of Hash? Probably false. I cannot guess > from the name what it might represent. Basically: Midterm exam => 30% Term Paper => 30% Final Exam => 40% kind of thing. A better name might be CourseRequirements. David -- David Alan Black home: dblack@candle.superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav