Re: Difference between inheritance and package use

[jls@netcom.COM (Jim Showalter)]

>How does (or more properly, how will) the upcoming addition of
>inheritance and object oriented stuff (for lack of a better word at
>the moment) differ from the definition of something in a package and
>its use later?

Think of two trees, one built using current Ada mechanisms for
abstraction, such as packages, 'with'ing, and private types,
the other tree built using inheritance.

In the first tree, sub-abstractions are at the leaves, and the
tree is built up from them, layer by layer, using 'with's and
types (probably records) that contain fields of the types of
the lower-level abstractions. In this tree, the most complex
type, and the type created most recently, is at the ROOT,
and the compilation dependency is from the root down to the
leaves.

In the second tree, the root may be a quite simple abstraction,
such as a universal object in the NIH library. More specialized
or complex abstractions are built in a line of descent from the
root to the leaves, with the leaves being the most recently
created abstractions. Note that in this case the compilation
dependency is UP the tree, from the leaves to the root.

Which of these is better? Well, there certainly does seem to
be a lot of argument about it. We know more about the first
kind of tree, because that's how almost all software has been
built traditionally (the information models used in MIS are
this kind of tree, and MIS accounts for 70% of all software [die,
COBOL, die]). On the other hand, there are a growing number of
people who believe strongly that the old way of doing things
is all wrong, that the new kind of tree is far superior, and
they'll chew your leg off at the hip if you give them any static
about it. ;-)

I have been wondering for some time if there isn't some kind of
bifurcation in people's cognitive styles that leads them to favor
one kind of tree over the other. I've had lots of inheritance
evangelists assert that inheritance trees are more "intuitive"
and "natural" and that they more closely model the problem space,
and yet, frankly, if this is true I wonder why so many people have
so gosh darned much trouble USING inheritance to build class libraries
that are actually good for something (I direct you to comp.object
for recent threads containing ample complaining about this very
difficulty). Furthermore, I keep looking around in my own software
projects for areas just screaming out for inheritance, and, while
I do find them, I find a lot MORE cases where the more traditional
tree is a considerably less artificial approach. This is what leads
me to ask (and get a lot of flak for asking) whether the wonders of
inheritance haven't been a wee bit oversold...

For example, I look around in nature and, yes, I do find examples of
inheritance. But I also find tractors. And there are, to the best
of my ability to discern their presence, scant few examples of
inheritance in tractors. What I find in tractors is subassemblies
(big ones, such as chassis, electrical, etc--subsystems), which
in turn are decomposed into smaller components such as differentials,
which are in turn decomposed into yet smaller components such as
wrist pins and gaskets and knobs. And so forth, all the way down
to quarks. And what is true for tractors is true for the human
body, airplanes, telephones, and just about every other physical
object I come into contact with--it is built up from smaller pieces.

Or am I missing something?

P.S. Note that I've said nothing above about genericity, which can
     be a feature of either kind of tree. This is because this
     makes things so complicated I don't want to even try to type
     it all in.
-- 
*** 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++.    *