Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: PolyMorphism (default? virtualness)
Keywords: virtual, leaf
Message-ID: <54370@microsoft.UUCP>
Date: 30 Apr 90 18:47:21 GMT
References: <1990Apr10.112351.24301@athena.mit.edu> <6170016@hpindda.HP.COM> <1204@calmasd.Prime.COM> <54226@microsoft.UUCP> <132@logo.procase.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 33

>"leaf" classes are a myth - identify any class as a "leaf" 
>an I will immediately prove you wrong by deriving from it.

Okay, I'll bite.  I claim the following class *is* a leaf class.  Prove
me wrong by deriving from it:


class LEAF
{
private:
	LEAF() {}
	LEAF(const LEAF&) {}
	LEAF& operator=(const LEAF&) { return *this; }
public:
	void Print() {printf("I'm a leaf\n");}
	static LEAF& New() { return *new LEAF; }
};


In any case, I believe this is the same old argument again.  If one believes
that inheritance is the more important property, one insists that encapsulation
must be subjugated to inheritance.  If one believes that encapsulation is
more important than inheritance, one points out that inheritance can always
break a superclass.  My claim would be that since in real life more than
half the classes people create *are* leaf classes, that is, classes which
are *not* being derived from, maybe it would behoove one to admit to such 
a distinction, and use it to one's advantage.  This need not be an end
to code reuse.  One can imagine placing the bulk of one's effort into
reusable "parent" classes, and only placing a small amount to code into
the non-reusable leaf classes.  The advantage would be that the leaf classes
are now a strictly encapsulated unit, and people can demonstrably argue
about whether those leaf classes work right or not -- such arguments can
never be resolved for non-leaf classes!