Xref: utzoo comp.lang.c++:6488 comp.object:942 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sundc!potomac!adiseker From: adiseker@potomac.ads.com (Andrew Diseker) Newsgroups: comp.lang.c++,comp.object Subject: Re: Inheritance vs. Composition Summary: my opinions only Keywords: inheritance composition multiple inheritance Message-ID: <8361@potomac.ads.com> Date: 15 Feb 90 02:05:28 GMT References: Reply-To: adiseker@potomac.ads.com (Andrew Diseker) Distribution: na Organization: Advanced Decision Systems -- Arlington, Va Lines: 54 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >I'm curious as to the reasons that one might use inheritance (derivation of a >new object from the definition of an old object) and the reasons that one >might use composition (wrapping multiple objects in another object). I have >been getting definitions around my work area that tend to conflict with my own >views and I'd like to build a body of evidence one way or the other in order >to help make my own views understood. Anyone care to provide their >definitions with examples as to how to apply their definitions? > >-- >=================================================================== >David Masterson Consilium, Inc. >uunet!cimshop!davidm Mt. View, CA 94043 >=================================================================== >"If someone thinks they know what I said, then I didn't say it!" What follows are my opinions only, flames will be gleefully ignored (I've been roasted by the best %^). From my experience working with and having discussions with some excellent OO programmers, I think the answer to the first question about derivation could be this: If there is an existing definition of an object that is close ( however you define that ) to what you want to use, then use your language's inheritance mechanism to create a copy of the definition and modify the parts that don't do quite what you want, and add whatever you need for any extra functionality. There, I didn't use the dreaded 'c' word, didn't mention data hiding, or any other religious terms. I tried to keep it general enough that it could even apply to (gag, choke) ADA. Now, however, it's time to don the asbestos suit. The second part of your question, referring to composition classes, is a matter of strong opinions on two sides. My personal reason for using composition objects is to circumvent the need for multiple inheritance. If I have two or more classes which exhibit the functionallity I need, and which contain the data in which I'm interested, then one object which contains instances of those classes and which allows whatever access is needed to those instances, is all I need. I just haven't seen any schemes for MH ( acronyms, anyone? ) that are general enough to be effective, and specific enough to cover all the holes. If you want to know what I'm talking about, just watch the next hundred or so responses to this post! %^) %^) %^) I really hate to have my compiler ( environment, whatever ) bogged down trying to prevent or otherwise handle the abiguities that naturally arise when you try to munge multiple, possibly disparate, possibly related classes. I call it a "what happens when cousins marry?" problem. Ahem. Now that I've offended any number of people, I'll step aside and watch the mayhem. Hope I've helped in some way, though. -- Andrew Diseker ( )-( ) Mouse-Tested! Advanced Decision Systems /o o\ Hacker-Approved! UUCP: sun!sundc!potomac!adiseker / =v= \ ,--_ Internet: adiseker@potomac.ads.com ;;---;; `--'