D
Dan McLeran
My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266
My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266
Dan McLeran said:My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266
True. Sometimes that is the intent.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 as well.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.
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.Is there a reason why the virtual functions cannot be in the protected
section?
It would definitely be better to make this member data private and provide getter/setter methods.(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.)
when construction high quality software.Dan said:My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266
Yes, I should update the code with more functionality in the base class.needed in the future -- who knows, maybe they won't be concrete but abstract
behaviors -- we don't know the future).
It combines the public class interface with the virtual interface. It's debatableHow would getting rid of
press{Brake|Gas}, making go and stop virtual and moving implementation there
would make this code worse?
I'm not sure I buy their explanation of why this is not a good idea.(A good explanation of how it would improve the code
is in the "Consequences" section of the Wikipedia article you cited).
Then compiler might issue some 'hidden name' warning which would bring theDan 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.
The basic idea here is that adding complexity makes code more fragile (moreI'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.
Dan McLeran wrote:
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").
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.