Re: Difference between inheritance and package use

[orville@weyrich.UUCP (Orville R. Weyrich)]

In article <1991Jun23.030631.8027@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>>I think you've actually defined when each "branch" of the tree is utilized
>>without realizing it. Sure, there are tractors. And they are forms of 4 wheeled,
>>utilitarian locomotion, which are a sub-class of wheeled transportation and
>>a peer class to 4 wheeled recreational vehicles. Wheeled transportation is
>>a form of land vehicle, which is a subclass of vehicles in general.
>
>Indeed. The problem with this is, if I'm trying to build a d*mned TRACTOR,
>why on earth would I want to have to drag around the entire tree of Things
>That Move Through Spacetime just to do so? Yes yes yes--I understand the
>notion of reuse, but I can reuse pistons and wristpins and all the
>subcomponents used to build a tractor (this, last time I looked, was sort
>of how most stuff WAS built), so in what way is this better or worse?
>If I want to build tractors, I grab a bunch of REUSABLE subcomponents and
>put them together to build a tractor. This seems--to my cognitive style,
>at least--a far more intuitive way to build a tractor than to try to 
>specialize it off of some sort of more general Vehicle_Thing (or, god
>forbid, to try to MULTIPLY-inherit it from a Farm_Thing and a Vehicle_Thing).

Since I you and I have both seen lots of tractors, I agree that simply 
assembling a tractor out of off-the shelf components makes a lot of intuitive
sense. It is intuitive precisely because we have seen a lot of tractors and
have internalized the general design of that sort of Vehicle_thing.

But suppose that we had never seen a tractor before. In this case our
intuition might fail us, and we might find ourselves groping for analogies
to this [strange] idea of a thing which moves and pulls farm implements the
same way great-grandpa and the old grey mare used to. In this case, inheritance
might be an important part of the cognitive process.

I go on to suggest that you plan to throw the first one away. That is, let your
creative juices flow to create the first prototype tractor using the OO
paradigm. Now that you've got it, you have probably developed enough intuition
for the next step: look to see what the reusable components
seem to be, and design the second model using standard off-the shelf components.
[Your analysis may suggest some new components that you want to add to your
on-the-shelf inventory].

But even still, you might find yourself saying things like: Yeah, I need a 
radiator. But make it's cooling fins a bit larger than the standard size,
because the chaff tends to clog the standard size.

My conclusion: a good designer alternates growing his/her trees in both 
directions. Which mode predominates depends on how well the designer
already understands the problem, on the designer's preferred cognitive
processes, and on the tools and libraries that the designer has available.

>
>On this, we agree strongly. My point in the original post was NOT that
>inheritance trees are useless, or that aggregation trees are the only
>way to build software. My point (and if you reread it I think you'll
>agree that I made this point) was that both seem to work, they both
>have advantages and disadvantages, and that claiming the supremacy
>of one over the other makes as much sense as any other black-and-white
>argument (e.g. nature vs nurture, punctuated equilibrium vs gradualism,
>etc). As Gulliver told the warring factions in his Travels: "Open your
>egg from the CONVENIENT end.".

I like that quote. I'm going to have to re-read my Johnathan Swift.
Please pardon me in advance if I start making any outrageous 'modest'
proposals. :-)

[Dare I go so far as to suggest that engineers prefer to construct
artifacts by agregation of standard sub-components, while scientists
and artists prefer to construct artifacts by inheritance and specialization
of abstract concepts? That would imply that software engineers prefer Ada,
while computer scientists and artsy-fartsy hackers prefer C++.]

Nah -- that is too modest to propose. :-).

--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************