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

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.

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

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

Quote:

---

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."

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

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

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

Thanks Mats,


Question answered.

Quote:

---

Originally Posted by matsp

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