Private Virtual Methods

Discussion in 'C++' started by Dan McLeran, Apr 24, 2012.

  1. Dan McLeran

    Dan McLeran Guest

    Dan McLeran, Apr 24, 2012
    #1
    1. Advertising

  2. Dan McLeran

    Dan McLeran Guest

    On Tuesday, April 24, 2012 3:57:49 PM UTC-6, Dan McLeran wrote:
    > My blog post on private virtual methods (a.k.a. Non-virtual Interface Idiom): http://wumbocode.com/wordpress/?p=266


    Yes, it is simple on purpose. It's always tricky to put in enough detail to illustrate the point without asking people to read a ton of code. Good point on tmain. Thanks for the comment.
     
    Dan McLeran, Apr 25, 2012
    #2
    1. Advertising

  3. Dan McLeran <> wrote:
    > 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.)
     
    Juha Nieminen, Apr 26, 2012
    #3
  4. Dan McLeran

    Dan McLeran Guest

    > 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.
     
    Dan McLeran, Apr 26, 2012
    #4
  5. Dan McLeran

    Pavel Guest

    Dan McLeran wrote:
    > 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
     
    Pavel, Apr 27, 2012
    #5
  6. Dan McLeran

    Dan McLeran Guest

    > 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.
     
    Dan McLeran, Apr 27, 2012
    #6
  7. Dan McLeran

    Pavel Guest

    Dan McLeran wrote:
    >> 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.

    Then compiler might issue some 'hidden name' warning which would bring the
    author's attention to the issue.
    >
    >> (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.
    >

    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
     
    Pavel, Apr 28, 2012
    #7
  8. Dan McLeran

    Guest

    On Friday, April 27, 2012 5:40:59 AM UTC+1, Pavel wrote:
    > Dan McLeran wrote:


    > > 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?


    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.

    > 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
     
    , Apr 29, 2012
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. qazmlp
    Replies:
    19
    Views:
    830
    Daniel T.
    Feb 4, 2004
  2. John Goche
    Replies:
    10
    Views:
    797
    Marcus Kwok
    Dec 8, 2006
  3. earthwormgaz
    Replies:
    3
    Views:
    366
    Michael Doubez
    Mar 11, 2010
  4. Daniel Finnie
    Replies:
    3
    Views:
    210
    Logan Capaldo
    Dec 16, 2006
  5. Frank Meyer

    Private methods not so private?

    Frank Meyer, Aug 1, 2007, in forum: Ruby
    Replies:
    14
    Views:
    306
Loading...

Share This Page