Re: Override public virtual Functions with private Functions?
On May 28, 2:01 am, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:
Daniel Pitts wrote:
Chris Gordon-Smith wrote:
Daniel T. wrote:
On May 27, 8:56 am, Chris Gordon-Smith <use.addr...@my.homepage>
wrote:
Daniel T. wrote:
If some user of the derived class does up-cast
and then call the base class member-function, would that necessarily=
be an error?
I don't think I would call it an error, but it would not be how I
intend the class to be used. The code that uses my class is now more
complex, because sometimes it uses the base class interface directly,=
and sometimes uses it by up-casting.
That latter comment is a strong reason to go ahead and make the member=
-
function public in the derived class.
Not really. The fact that up-casting would be necessary is a strong
indication that the class is not intended to be used in this way. By on=
ly
using the base class interface we keep the calling code simple and avoi=
d
any up-casting.
Chris Gordon-Smith
www.simsoup.info
The real question is, why don't you want people to call
Derived->baseMethod()? What harm comes from it, and what benefit comes
from preventing it?
The benefit is standardisation and simplification. The base
and its derived classes are designed to be used
polymorphically in a standard way through the base class's
interface.
One of the characteristics of inheritance is normally that the
Base class' interface is part of the derived class' interface,
i.e. if I have something like:
struct Base { void f() ; } ;
struct Derived : Base { void g() ; } ;
then the "interface" defined by Derived includes both f() and
g().
--
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