Virtual function design pattern

This is a discussion on Virtual function design pattern within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, About the virtual function design pattern mentioned, http://www.parashift.com/c++-faq-lit....html#faq-23.4 I do not quite understand what does this statement mean ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    Virtual function design pattern

    Hello everyone,


    About the virtual function design pattern mentioned,

    http://www.parashift.com/c++-faq-lit....html#faq-23.4

    I do not quite understand what does this statement mean "Assuming they're protected, they probably shouldn't be virtual: if the derived class doesn't like the behavior in one of them, it doesn't have to call that method." Any ideas?

    I quote the whole paragraph here,

    --------------------
    Suppose you have the exact opposite situation from the previous FAQ, where you have a method whose overall structure is different in each derived class, yet it has little pieces that are the same in most (if not all) derived classes. In this case you'd put the overall algorithm in a public virtual that's ultimately defined in the derived classes, and the little pieces of common code can be written once (to avoid code duplication) and stashed somewhere (anywhere!). A common place to stash the little pieces is in the protected part of the base class, but that's not necessary and it might not even be best. Just find a place to stash them and you'll be fine. Note that if you do stash them in the base class, you should normally make them protected, since normally they do things that public users don't need/want to do. Assuming they're protected, they probably shouldn't be virtual: if the derived class doesn't like the behavior in one of them, it doesn't have to call that method.
    --------------------


    thanks in advance,
    George

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,275
    The "they" refers to the "little pieces", i.e., functions that the base class provides in view that subclasses might (or might not) have use for them. If the subclasses do not have use for them, the subclasses simply do not use these "little pieces", thus there is no need to make these "little pieces" virtual as no one will override them.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    I think for the "little piece", derived class can utilize it and overrides it, so why not make it virtual and protected?

    Sorry, I may not fully grasp your points. It is appreciated if you could provide more description.

    Quote Originally Posted by laserlight View Post
    The "they" refers to the "little pieces", i.e., functions that the base class provides in view that subclasses might (or might not) have use for them. If the subclasses do not have use for them, the subclasses simply do not use these "little pieces", thus there is no need to make these "little pieces" virtual as no one will override them.

    regards,
    George

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,275
    I think for the "little piece", derived class can utilize it and overrides it, so why not make it virtual and protected?
    If that is what you think, then make it virtual and protected. It is as simple as that. That very FAQ section also notes: "First, stay away from always/never rules, and instead use whichever approach is the best fit for the situation."
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks laserlight,


    I have made some thinking. So, I think you mean for the small piece methods, they have common code for both base and derived class. It means derived class and base class should share common code?

    So, making the "common" methods virtual will make developer confused about potential efforts to override and provide differences (polymorphism)?

    Quote Originally Posted by laserlight View Post
    If that is what you think, then make it virtual and protected. It is as simple as that. That very FAQ section also notes: "First, stay away from always/never rules, and instead use whichever approach is the best fit for the situation."

    regards,
    George

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The point of making a function virtual is that it can be overridden by a derived class.

    If the point of the small common function is to supply some simplistic function, making it virtual is not much use, because, as you hint, it makes a user of the derived class think that it's something that may be, should be or must be [depending on the general class implementation] overridden by the derived class. If the intention is simply to supply a basic, common utility function, then it should not become a virtual function - because it's then not a basic common utility function, but a virtual member function.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    Question answered.

    Quote Originally Posted by matsp View Post
    The point of making a function virtual is that it can be overridden by a derived class.

    If the point of the small common function is to supply some simplistic function, making it virtual is not much use, because, as you hint, it makes a user of the derived class think that it's something that may be, should be or must be [depending on the general class implementation] overridden by the derived class. If the intention is simply to supply a basic, common utility function, then it should not become a virtual function - because it's then not a basic common utility function, but a virtual member function.

    --
    Mats

    regards,
    George

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  2. Game Pointer Trouble?
    By Drahcir in forum C Programming
    Replies: 8
    Last Post: 02-04-2006, 02:53 AM
  3. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 01:03 PM
  4. structure vs class
    By sana in forum C++ Programming
    Replies: 13
    Last Post: 12-02-2002, 07:18 AM
  5. C++ XML Class
    By edwardtisdale in forum C++ Programming
    Replies: 0
    Last Post: 12-10-2001, 11:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21