sharif@lamar.colostate.edu (Thomas Abdallah) (03/04/91)
I have a question regarding inheritance.
In all my readings I have not found a decisive answer to the question can
objects inherit an attribute through more than one channel?
Say that I have the following construct:
Water
+-----------------------+ | | +----------------+
| +----------+ +--+ |
v v v v
Ocean Lake Beer <--------- Hops
Base class WATER has an attribute, say w' which is inherited by Derived classes
OCEAN, LAKE, and BEER, and HOPS. Now BEER also inherits the attribute w' from
HOPS. Is this a legal OO construct? If not, why not?
I'm in the middle of a discussion in a graduate seminar and am looking for an
authoritative answer to this question. Any and all comments/references/etc.
are welcome.
Thomas-Sharif Abdallah
Grad Student (Computer Information Systems)
Colorado State University
Fort Collins, CO USA
-------------------------------------------------------------------------------
internet : sharif@lamar.colostate.edu
-------------------------------------------------------------------------------plogan@mentorg.com (Patrick Logan) (03/05/91)
In article <13349@ccncsu.ColoState.EDU> sharif@lamar.colostate.edu (Thomas Abdallah) writes: I have a question regarding inheritance. In all my readings I have not found a decisive answer to the question can objects inherit an attribute through more than one channel? There are no decisive answers, in OOP nor programming in general. The universe is wide open and that's the source of all problems. Say that I have the following construct: Water +-----------------------+ | | +----------------+ | +----------+ +--+ | v v v v Ocean Lake Beer <--------- Hops Base class WATER has an attribute, say w' which is inherited by Derived classes OCEAN, LAKE, and BEER, and HOPS. Now BEER also inherits the attribute w' from HOPS. Is this a legal OO construct? If not, why not? The answer depends on the programming language used. It could also depend on what you mean by 'legal'. Your hierarchy appears to confuse whole/part design with class/subclass design. For example, water is an ingrediant of beer, but most people would not consider beer to be a kind of water. On sharing base classes: the various OOPLs have their own rules on combining classes and how to resolve shared base class issues. I'm in the middle of a discussion in a graduate seminar and am looking for an authoritative answer to this question. Any and all comments/references/etc. are welcome. I would suggest looking for references that discuss the difference between whole/part (aggregation) and class/subclass concepts. The reference manuals of languages that allow multiple inheritance should provide thorough discussions of how they handle shared base classes as well as other situations that can result in name clashes. -- Patrick Logan, uunet!mntgfx!patrick_logan -or- patrick_logan@mentorg.com Mentor Graphics Corp. 8500 SW Creekside, Beaverton, Oregon 97005-7191 => Note that I have a new email address listed above!
giddy@astrix.trl.oz.au (David Giddy) (03/05/91)
In article <13349@ccncsu.ColoState.EDU>, sharif@lamar.colostate.edu (Thomas Abdallah) writes: > I have a question regarding inheritance. > > In all my readings I have not found a decisive answer to the question can > objects inherit an attribute through more than one channel? > > Say that I have the following construct: > > Water > +-----------------------+ | | +----------------+ > | +----------+ +--+ | > v v v v > Ocean Lake Beer <--------- Hops > > > Base class WATER has an attribute, say w' which is inherited by Derived classes > OCEAN, LAKE, and BEER, and HOPS. Now BEER also inherits the attribute w' from > HOPS. Is this a legal OO construct? If not, why not? The situation you are describing here is known as repeated inheritence. It will result in clashes in the names of inherited attributes which must be resolved in one way or another. There are two basic ways of solving this conflict: renaming and sharing. The combination of these used depends on the language and particular situation. A good reference to this problem is "Object Oriented Software Construction" by Bertrand Meyer (published by Prentice Hall), specifically section 11.6. On another point: I question your examples' use of inheritence to describe the relationships between beer, water and hops. The inheritence relation can be thought of as an "is a" relation and I question whether Beer "is a" Hops (whether the beer in your part of the world "is a" Water is for you to say :-)). I think the client-supplier ("has a") relation would be more appropriate! Regards, David. ______________________________________________________________________________ David Giddy, Voice: +61 3 541 6388 Fax: +61 3 543 1944 Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, AUSTRALIA Internet: d.giddy@trl.oz.au X400: g=david s=giddy ou=trl o=telecom prmd=telecom006 admd=telememo c=au
hmm@julien.informatik.uni-dortmund.de (Hans Martin Mosner) (03/05/91)
In article <13349@ccncsu.ColoState.EDU>, sharif@lamar.colostate.edu (Thomas Abdallah) writes: |> I have a question regarding inheritance. |> |> In all my readings I have not found a decisive answer to the question can |> objects inherit an attribute through more than one channel? |> |> Say that I have the following construct: |> |> Water |> +-----------------------+ | | +----------------+ |> | +----------+ +--+ | |> v v v v |> Ocean Lake Beer <--------- Hops |> |> |> Base class WATER has an attribute, say w' which is inherited by Derived classes |> OCEAN, LAKE, and BEER, and HOPS. Now BEER also inherits the attribute w' from |> HOPS. Is this a legal OO construct? If not, why not? |> Why is it that almost every example of multiple inheritance is wrong ??? At least in my view of the world, inheritance means is-kind-of. In your example, you have a *contains* relationship between Ocean & Water, Lake & Water, Beer & Water, Beer & Hops (the last one is simplified, of course). So the mechanism at work here is composition (& probably behavioral delegation), but not inheritance. At least in MY country, beer is NOT a kind of water :-) Now for the attribute propagation through more than one channel, this is perfectly legal in those object-oriented languages that I know. For example, the bitterness attribute of beer might be computed from the bitterness and relative amount of the hops used for brewing the beer. No need for inheritance at all! Hans-Martin
johnson@cs.uiuc.EDU (Ralph Johnson) (03/07/91)
In article <13349@ccncsu.ColoState.EDU>, sharif@lamar.colostate.edu (Thomas Abdallah) writes: |> I have a question regarding inheritance. |> |> In all my readings I have not found a decisive answer to the question can |> objects inherit an attribute through more than one channel? |> |> Say that I have the following construct: |> |> Water |> +-----------------------+ | | +----------------+ |> | +----------+ +--+ | |> v v v v |> Ocean Lake Beer <--------- Hops |> |> This is a common problem, and it comes from a common misconception about inheritance. I would structure the entire hierarchy differently. First, Beer and Water are subclasses of Liquid, and maybe also of Food (or EdibleSubstance). Ocean and Lake are subclasses of BodyOfWater. Oceans and Lakes contain water, because you can take water out of a Lake and pour it into a Lake, but Lake water is not a different kind of water than water that comes out of the tap. Ocean water, on the other hand, is a special kind of water! Again, Beer and Hops are related by manufacture. You wouldn't say that Bread is a subclass of Salt, even though it contains Salt. Similarly, Tree is not a subclass of Sunlight.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (03/08/91)
In article <13349@ccncsu.ColoState.EDU> sharif@lamar.colostate.edu (Thomas Abdallah) writes: >I have a question regarding inheritance. > >In all my readings I have not found a decisive answer to the question can >objects inherit an attribute through more than one channel? > >Say that I have the following construct: > > Water > +-----------------------+ | | +----------------+ > | +----------+ +--+ | > v v v v > Ocean Lake Beer <--------- Hops > > >Base class WATER has an attribute, say w' which is inherited by Derived classes >OCEAN, LAKE, and BEER, and HOPS. Now BEER also inherits the attribute w' from >HOPS. Is this a legal OO construct? If not, why not? Several people have already answered, most of them pointing out that the inheritance relations are not very sensible if the names of these classes are to be taken literally. It is indeed very common that one confuses an inheritance hierarchy (is kind of) with a part hierarchy (is part of). I'll omit this part of the problem and continue the discussion without reference to the supposed real-world semantics of these classes. In principle, if Beer is a subclass of Hops which is a subclass of Water, then Beer is also a subclass of Water; thus there is no idea in declaring Beer also an immediate subclass of Water. However, I see you are using C++ terminology -- in C++ Hops may inherit Water privately and this kind of hierarchy could then be sensible; but in that case Hops is not regarded as a _subtype_ of Water. A certainly sensible and interesting situation occurs if you have a "fork-join" kind of hierarchy, the simplest possible being A / \ B C \ / D I dislike the way this is handled in Bertrand Meyer's "Object-oriented Software Construction" (a book that I hold in high esteem in general). I agree better, but not completely, with Jorgen Lindskov Knudsen's paper in the ECOOP'88 proceedings. While writing my own paper "Disciplined inheritance" for ECOOP'89, I totally agreed with the way that the multiple-inheritance addition to C++ (a language that I do _not_ hold in high esteem in general) was designed. More recently I have found that there is at least one clear problem even in the C++ approach. Essentially, the "virtuality" of a base class can be "too strong" (too global) in more complex situations where some of the derivations are private. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)