From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_50,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5784 comp.object:3780 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada,comp.object Subject: Re: Difference between inheritance and package use Message-ID: <1991Jun23.030631.8027@netcom.COM> Date: 23 Jun 91 03:06:31 GMT References: Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: >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++. *