Private Virtual Methods

J

Juha Nieminen

Dan McLeran said:
My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266

When specializing (non-pure) virtual functions in a derived class, it's
sometimes (or even often) the case that one wants to call the parent class
implementation as well. However, this becomes impossible if said
implementation is private.

Suppose that in your example I would want to make a special type of 'Car'
by inheriting from it, and in its pressBrake() and pressGas() specializations
I would want to call the ones in the parent 'Car' class. Since they are
private, it's not possible.

Is there a reason why the virtual functions cannot be in the protected
section?

(Also, putting member variables in a protected section is usually considered
dubious design. With respect to derived classes they are effectively public,
and as we know, public member variables are usually a bad idea, save for
some really exceptional cases.)
 
D

Dan McLeran

When specializing (non-pure) virtual functions in a derived class, it's
sometimes (or even often) the case that one wants to call the parent class
implementation as well. However, this becomes impossible if said
implementation is private.
True. Sometimes that is the intent.
Suppose that in your example I would want to make a special type of 'Car'
by inheriting from it, and in its pressBrake() and pressGas() specializations
I would want to call the ones in the parent 'Car' class. Since they are
private, it's not possible.
True as well.
Is there a reason why the virtual functions cannot be in the protected
section?
If one wanted to do what you've talked about above, that would be the way to go. If you wanted to explicitly prevent this behavior, then making them private is the answer. It all depends upon the behavior you're going for. Inthe case of this post, I was going for the simplest example which illustrates the idea.
(Also, putting member variables in a protected section is usually considered
dubious design. With respect to derived classes they are effectively public,
and as we know, public member variables are usually a bad idea, save for
some really exceptional cases.)
It would definitely be better to make this member data private and provide getter/setter methods.
 
P

Pavel

Dan said:
My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266
when construction high quality software.
=> when constructing high quality software?

I am slightly confused with the point of your blog entry.

Wikipedia article you cited clearly stated the purpose of the exercise: to
implement Template Method pattern (wordily aka "before and after code fragments
for entire class hierarchy"). NVI is a natural way of getting this particular
task done.

Your code does not have any "before" or "after" conditions (and if they are
needed in the future -- who knows, maybe they won't be concrete but abstract
behaviors -- we don't know the future). How would getting rid of
press{Brake|Gas}, making go and stop virtual and moving implementation there
would make this code worse? (A good explanation of how it would improve the code
is in the "Consequences" section of the Wikipedia article you cited).

-Pavel
 
D

Dan McLeran

Your code does not have any "before" or "after" conditions (and if they are
needed in the future -- who knows, maybe they won't be concrete but abstract
behaviors -- we don't know the future).
Yes, I should update the code with more functionality in the base class.
I was trying to show the private virtual interface as separate from the public
non-virtual interface without cluttering it up too much.
How would getting rid of
press{Brake|Gas}, making go and stop virtual and moving implementation there
would make this code worse?
It combines the public class interface with the virtual interface. It's debatable
whether or not this is "worse". This is kind of a problem with C++ generally.
A child class could define a new pressBrake even though the base class pressBrake is
non-virtual.
(A good explanation of how it would improve the code
is in the "Consequences" section of the Wikipedia article you cited).
I'm not sure I buy their explanation of why this is not a good idea.
They are basically saying if you do something twice unintentionally then
this could lead to bad behavior. Well, you could say that about a lot of instances
of polymorphic code whether or not you use this idiom. I do agree that there could be
some downside to this idiom but I don't think their example is very good.
 
P

Pavel

Dan said:
Yes, I should update the code with more functionality in the base class.
I was trying to show the private virtual interface as separate from the public
non-virtual interface without cluttering it up too much.

It combines the public class interface with the virtual interface. It's debatable
whether or not this is "worse". This is kind of a problem with C++ generally.
A child class could define a new pressBrake even though the base class pressBrake is
non-virtual.
Then compiler might issue some 'hidden name' warning which would bring the
author's attention to the issue.
I'm not sure I buy their explanation of why this is not a good idea.
They are basically saying if you do something twice unintentionally then
this could lead to bad behavior. Well, you could say that about a lot of instances
of polymorphic code whether or not you use this idiom. I do agree that there could be
some downside to this idiom but I don't think their example is very good.
The basic idea here is that adding complexity makes code more fragile (more
moving parts <=> more potential breakage points). The whole goal of "good
software design" in general is to make maintenance cheaper, which IMHO includes
less error-prone. That is why I am usually against adding moving parts when they
are not necessarily to make the code correct (and usually keen to delete all
parts that can be deleted while keeping it correct).

-Pavel
 
G

Guest

Dan McLeran wrote:
when construction high quality software.
=> when constructing high quality software?

whats wrong with that?
I am slightly confused with the point of your blog entry.

Wikipedia article you cited clearly stated the purpose of the exercise: to
implement Template Method pattern (wordily aka "before and after code fragments
for entire class hierarchy").

sounds an odd characterisation of the template patter.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top