From: Pete McBreen <pete@...>
Date: 2003-02-12T14:08:29+09:00
Subject: Re: inheriting from base classes

On Tuesday, February 11, 2003, at 07:26  AM, 
dblack@candle.superlink.net wrote:
>
> 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."

Agreed. In Smalltalk, some developers do talk about inheritance purely 
for code sharing purposes as distinct from real subclassing. Since Ruby 
shares much of Smalltalk's dynamic nature, the same situation arises. 
The only challenge occurs when you find that there are some methods you 
do not want to expose in the code sharing subclass.

>
>>   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.

Someone else already pointed out the obvious one of the Array getting 
the wrong objects put into it, but Test Driven Development is a good 
fix for that.

A pragmatic approach (with apologies to Dave and Andy) is to say that 
in Ruby it doesn't matter, because if and/or when it becomes a problem, 
changing the implementation of the ClassRoster will not have massive 
consequences. After all it is not like we have to recompile 
everything:-)

>
>>   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.

Now that I understand the context, AssignmentValues looks reasonable 
("intuitive in hindsight" is how I refer to this). CourseRequirements 
invokes the idea of courses that must be taken before this one.

Pete
----
Pete McBreen, McBreen.Consulting , Cochrane, AB
http://www.mcbreen.ab.ca/

Author, "Software Craftsmanship The New Imperative"
Winner of 2002 SD Productivity Award

Author:  "Questioning Extreme Programming"
Addison-Wesley (c) 2003