Xref: utzoo comp.lang.c++:6451 comp.object:929 Path: utzoo!attcan!uunet!microsoft!jimad From: jimad@microsoft.UUCP (JAMES ADCOCK) Newsgroups: comp.lang.c++,comp.object Subject: Re: Inheritance vs. Composition Message-ID: <50013@microsoft.UUCP> Date: 13 Feb 90 17:42:42 GMT References: <10465@alice.UUCP> Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 23 In article <10465@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >The key difference in C++ is that if class D inherits [publicly] from >class B, then you can pass a D argument to any function that takes >a B parameter. Another way of looking at it is that if you derive >D from B, then a D object does [at least] everything a B object does. >If you define a class D with a B member, then you must define every >operation you want a D to be able to perform, even if that is replicating >many of the B operations. More particularly, if you want to be able to use D as a B--and then some, one must either/or inherit from B and make non-virtual methods of B available unchanged from D, and/or inherit from B and possibly change some of the virtual methods of B to reflect the added functionality of D. In either case, the public methods of B can be thought of as a protocol that D must conform to. The important thing to note is that in C++, unlike some other OOPLs, even if one delared the same-named methods as B in a class D' *not* derived from B, those same-named methods *would-not* match B's protocol. So D' could not be used as a B, even though D' *seemed* to have all the correctly-named methods necessary to act like a B. D can be used as a B only via inheritence.