Re: Difference between inheritance and package use

[jls@netcom.COM (Jim Showalter)]

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

>Looking at the problem this way, it seems that inheritance, etc. is better
>suited to decomposing the higher levels of abstraction, while packages, etc.
>are better suited (as mentioned in your example above) to implementation details.

I disagree. I do the higher level abstraction in terms of components that
are simply bigger--subsystems. They aren't inherited at all. They're just
more of the same idea--components built up from components, but they're
the largest components in the tree. Like, for example, a DBMS (note that
a DBMS is NOT inherited [yet] from Storage_Thing and Retrieval_Thing and
Query_Thing).

>I don't thinkg you see an example of an object-
>oriented LARGE system for a long time. Some hybrid of OOP and traditional
>decomp., maybe. 

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.".
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *