Re: Virtual private member functions
On Mar 29, 9:17 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
On Mar 28, 11:30 am, "Craig Scott" <audiofana...@gmail.com> wrote:
On Mar 28, 4:05 pm, "Salt_Peter" <pj_h...@yahoo.com> wrote:
On Mar 28, 12:50 am, "v4vijayakumar" <vijayakumar.subbu...@gmail.com>
wrote:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
Why should it be a compile time error? Private has to do with
accessibility - completely unrelated to whether its virtual or not.
What is preventing a public member function from calling a virtual
private member function?
Consider NVI (non-virtual interface) Idiom which does exactly that.
The non-virtual function is the accessible interface and the private
virtual function is the hidden worker-bee.
This sometimes bothers me. It could be argued that the virtual
functions should be protected rather than private, since sub-classes
might/will re-implement them and by making them private, subclasses
are prevented from explicitly calling the base class version as part
of their own implementation. This prevents subclasses from
implementing the function in ways such as "do the default thing plus
this other stuff....".
On the other hand, it could also be argued that the author of the base
class might want to prevent the virtual functions from being called in
any context other than the place the base class calls them. I can see
both sides, but I think we can be too hasty in just making them
private by default. It would seem that making them protected by
default might be more conservative.
I don't think you really need a "default". Design should decide
in each case.
Most of the time, the virtual functions will be pure virtual in
an abstract base class. In such cases, if the class has
invariants, or defines any sort of contract, the functions
should probably be private. Otherwise (e.g. inversion of call
situations, like the visitor pattern or a callback in an
observer), there's really no point in not making them public.
When a derived class provides an implementation, logically, most
of the time, you'd want to "finalize" the function, and not
allow any further derived class de redefine it. Your
implementation is part of how you maintain your class
invariants, and allowing a further derived class to replace it
with something else means that you can no longer be sure of
enforcing your contract.
Yes, I agree, but how come derived class can ever see private parts of
base class. Is this right?
They're called access specifiers for a reason: they control
access, not visibility. There are various historical reasons
for this, and one can argue about whether it is right or wrong
from a theorectical point of view, but it works well in
practice.
--
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