Xref: utzoo comp.lang.c++:6500 comp.object:948 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!ardent!jra!jss From: jss@jra.ardent.com Newsgroups: comp.lang.c++,comp.object Subject: Re: Inheritance vs. Composition Keywords: inheritance composition multiple inheritance Message-ID: <10246@ardent.UUCP> Date: 15 Feb 90 22:57:43 GMT References: <8361@potomac.ads.com> Sender: news@ardent.UUCP Reply-To: jss@jra.ardent.com () Distribution: na Organization: Ardent Computer Corp., Sunnyvale, CA Lines: 32 In article <8361@potomac.ads.com> adiseker@potomac.ads.com (Andrew Diseker) writes: > > 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. This may be good advice for "generic OO" but it is bad advice for C++. I believe that the "protected interface of a class" (i.e. the relation between a class and classes derived from it) must be specified just as carefully as the specification of any member, and if the original class was not designed with such an interface then you shouldn't be deriving from it. Many C++ classes are designed with a value semantics rather than an object semantics. That is, they are intended to have their values copied rather than pointers to them passed around. The classsical example is "complex". Even when it isn't obvious from the external interface, the implementation of a class may copy values around in various ways. It is almost always a mistake to derive from these classes. When I to use a class supplied by somebody else, I use it in the way it was designed to be used. When I want to copy code, I copy it. Jerry Schwarz