Re: virtual fn, destructor
On Dec 15, 12:52 pm, Martin Drautzburg <Martin.Drautzb...@web.de>
wrote:
James Kanze wrote:
On Dec 14, 1:35 am, Martin Drautzburg <Martin.Drautzb...@web.de>
But I understand you "contract" approach. Not limiting a
class'es usage by declaring everything public and virtual
isn't much of a conract. You want statements like "do not
use indoors" attached to a class, where I'd say: "let them
use it indoors, if they know what they're doing".
You've got your analogy backwards. The purpose of the
contract is to provide the necessary guarantees to the
client code. So that they can use it where ever
appropriate. It's really part of the basics of OO design.
I think you're going over the edge here. There may be good
reasons to limit a classes future use, but these seem to be
more related to the inner workings of C++ and not a matter of
"basic OO design". Tell that a Smalltalk guru an he will
probably tell you that C++ is not OO at all.
It's not a question of "limiting a class". It's a question of
establishing a definition of what the interface does, so that
client code can use it. Today, and in the future.
Actually I'd say that subclassing is *the* primary thing in
OO.
It seems like every OO guru has a different definition of OO:-).
Still, I tend to agree that inheritance and dynamic dispatch are
an important part. But that doesn't mean no constraints. The
interface defines a contract, which all of the derived classes
must fulfill if the interface is to be usable. And once you
have an implementation, further derivation is really only
acceptable if the implementation is designed for it (e.g.
template method pattern); generally, the implementation of the
different virtual functions will be designed to work together,
and overriding one, without overriding all, will cause class
invariants to fail unless the author of the implementation has
taken this possibility into consideration.
And of course, not everything is, nor should be, OO. Value
semantics and inheritance don't go well to gether, for example;
so-called "pure" OO languages generally avoid the problem by not
supporting values at all, but that just means you need some
extra rules to simulate them.
Without subclassing you are merely working with abstract data
types. If you are saying that working with ADTs is in many
cases more safe than working with classes, then you are
probably right. I would really hesitate to subclass e.g. a
file descriptor. But then again, if I ever felt the need to
teach a file descriptor new tricks, I would much rather create
a subclass that hacking my operating system kernel.
Wouldn't implementing a new class, which wraps the file
descripter, make more sense? (In practice, you generally can't
modify the semantics of a file descriptor without modifying
kernel code. For good reasons.)
But I am seeing this from a semantic point of view. There are
things in the real world, which can be classified and
specialized. You can say "a cat is special kind of animal". In
OO languages this relationship ("Is a special kind of") can be
expressed via sublassing. In the real world there are very few
concepts which cannot be specialized (maybe Life, Death and
Existance are exceptions). This is why I am always puzzeled
when classes are declared final, because it basicly states
that "there can never be a special kind of this thing".
I'm not sure that this applies. A base class (in a statically
typed language like C++ or Java, at least) defines a concrete,
bound interface, with a contract. The contract is necessary in
order for client code to use that interface. In the real world,
cats don't care whether they adhere to any contract or not; it's
up to you (or the cat) to cope with it. (For example, the class
Cat might implement a function legCount() to return 4, and a
function walk() which depended on legCount() == 4 in order to
work. In real life, there are cats that have lost a leg.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34