Re: Deriving from concrete types
Gene Bushuyev wrote:
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1151320889.159116.71540@b68g2000cwa.googlegroups.com...
Bernhard Jungk wrote:
[...]
If the base class isn't designed to be derivable, it shouldn't
be done with public inheritance.
You see. You've mixed the two. Inheritance is a C++
implementation technique; derivation is a design concept. If
the reason you are using inheritance is to implement derivation,
then you should ensure that your class is designed with
derivation in mind. If you are using it for some other reason,
you should ensure that your class meets the requirements for
whatever the reason.
Public inheritance defines a "is a" relationship
Public derivation defines a "is a" relationship.
It may or may not be. I don't favor making subtle distinctions
about inheritance and derivation, both are used
interchangeably to refer to the mechanism of creating subtypes
in C++.
The problem is that the two words are used interchangeably. Or
more strictly speaking, the problem is that we don't distiguish
through vocabulary two significantly different things: a design
concept and a C++ language structure. Now, it's true that the
C++ language structure was originally conceived to implement the
design concept (I think, anyway). But it remains a language
structure, and in modern C++, it is often used for other things.
Trying to force all uses of the language structure to conform to
rules which only apply to the design concept is, IMHO, an error.
Going back to the classic work of Barbara Liskov, where she
defined the substitution principle:
"What is wanted here is something like the following
substitution property: If for each object o1 of type S there
is an object o2 of type T such that for all programs P defined
in terms of T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T."
No problem with that, but she is talking about the design
concept here.
That pretty much restricts derivation to virtual functions,
If you don't have virtual functions, it is pretty clear that you
are not using C++ derivation to implement the design concept of
inheritance, but for some other reason.
For the rest, you seem to be making the same mistake I'm arguing
against: confusing the language structure used to implement it
with the design concept. WHEN derivation is used to implement
the OO design concept of inheritance, then it is clear that the
base class must have virtual functions, etc. When derivation is
used for other reasons (e.g. as when deriving from
std::iterator<...>), then other rules apply.
[...]
Inheriting from a large concrete class like std::vector is a
gratuitous violation of design rules, which has only problems
and no real advantages.
I agree here. While I think that there are many reasons to use
C++ derivation, and not just to implement the OO design concept
of inheritance, none of them can be just randomly applied. A
class must be designed to be a base class, regardless of the
reasons why it is to be used as a base class. There is no
doubt, for example, that std::iterator<> was designed to be used
as a base class, although there is no doubt in my mind that this
use of C++ derivation does not correspond to the OO design
concept of inheritance. There is also no doubt in my mind that
std::vector<> was not so designed, and that any use of it as a
public base class will run into problems. Not because it
doesn't conform to the rules of the OO design concept, per se,
but because it doesn't conform to the rules of any design
concept which would normally be implemented using it as a base
class in C++.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]