Xref: utzoo comp.lang.c++:6426 comp.object:915 Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!husc6!cmcl2!lanl!lambda!drich From: drich@klaatu.lanl.gov (David Rich) Newsgroups: comp.lang.c++,comp.object Subject: Re: Inheritance vs. Composition Message-ID: Date: 11 Feb 90 19:47:36 GMT References: Sender: news@lambda.UUCP Followup-To: comp.object Organization: Los Alamos National Laboratory Lines: 69 In-reply-to: cimshop!davidm@uunet.UU.NET's message of 11 Feb 90 08:50:56 GMT 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). David Masterson uunet!cimshop!davidm When I make use of "inheritance" as you've defined it, I'm typically creating an "is-a" relationship between the old and new object. In other words, I want the new object to behave like the old object plus some additional functionality, etc. When I think of "composition", I think of two kinds: (1) composition via multiple inheritance and (2) composition via encapsulation, or ownership (for lack of a better term). When I make use of (1), I'm simply applying the "is-a" relationship multiple times. When I do this, I know that I want the composite object to be able to have direct access to all the attributes and methods of its ancestors. However, when the composite object shouldn't really have direct access to the attributes and methods of its ancestors, each ancestor becomes an attribute of the composite object (in the form of an object reference). In other words, the composite object needs the functionality, but the relationship is not an "is-a" type. Here's an example from a simulation project that I'm working on. I've built up a map object that represents an interface to terrain data such as relief, vegetation, mobility, roads, rivers, etc. The map encapsulates this information and provides methods that will allow objects to query the state of the terrain, generate routes to move along, etc. The question that came up was how to give this functionality to objects that need to move around on terrain. Using multiple inheritance to give a truck, for example, the ability (among other things) to construct movement routes over terrain doesn't seem right to me. The inheritance mechanism gives the truck access to information that it really shouldn't have (e.g., the truck can change the state of terrain directly by modifying attributes). The alternative, it seems to me, is to give the truck a map attribute. That is, a reference to a map object through which it can deal with terrain appropriately (via the maps "public" interface and not "under the table" so to speack). I guess the point I'm trying to make here is that composition via multiple inheritance may give the composite object information it doesn't need or shouldn't have access to (if there isn't a natural "is-a" type relationship). Composition by encapsulation (which may not be an appropriate term since I just made it up) is a way around this. This "inheritance"/"composition" issue is one we've been trying to get a grasp on too. It seems that the line (for us anyway) is somewhat subjective. What's "is-a" to one person may not be to another. In a lot of ways, this may just be another "soap box" issue. Dave -- -- David Rich Military Systems Analysis Group (A-5) MS F602 Los Alamos National Laboratory Los Alamos, NM 87545 Phone: (505) 665-0726 Email: dor@lanl.gov