Re: Ok --- *enough* with the private virtual functions...
Gerhard Menzl wrote:
Carlos Moreno wrote:
What I *think* is the deal with this, is that instead of doing:
class B
{
public:
virtual void f();
};
class D : public B
{
public:
virtual void f();
};
I should do:
class B
{
public:
void f() { p_f(); }
private:
virtual void p_f();
};
class D : public B
{
private:
virtual void p_f();
};
I see how the above works --- but the thing is, I see it as having
the same effect as the first option (with the public virtual f() );
am I getting it wrong? (that is, is it a different thing that's
done as a recommended practice?), or maybe it is that I'm not seeing
some bad things that can happen with the first case that can not
happen with the second as a consequence of not having public virtual
functions?
Help? Please? Maybe one concrete example (as in, not class B and
class D) that shows how private virtual functions help?
I would be surprised if you were not familiar with the Template Method
pattern.
I'm not sure that I'd limit it to that. At least the way the
GoF speak of it, the template pattern is used to customize an
implementation (algorithm) in the base class, and is only
applicable in certain cases. I use the above pattern for
programming by contract, where the base class has no
responsibilities other than defining the contract, and find it
applicable in a very large percentage of the polymorphic
hierarchies I write. We may use the same C++ features in the
two cases, but I find them conceptually distinct.
In the first case, the base class version of f() is replaced
entirely. B
is completely bypassed when f() is called on a D object.
In the second case, it is assured that control passes first through
the
base class function, which gives the base class designer
opportunity to
impose mandatory precondition checks first, then let the derived class
do its work, and then perform postcondition checks. It's the canonical
way to implement programming by contract. Of course, this could be
subverted by hiding the non-virtual base class function in the derived
class, but this would be a Macchiavellian rather than a Murphian
blunder.
Again, it depends on the goals. There's nothing wrong with D
providing a different contract than B, in which case, the hiding
might be perfectly normal and acceptable. The important thing
is that if I have a pointer or a reference to B, I can count on
the contract that B gives, and that contract will be enforced by
B. If I want the contract for D, I can use dynamic_cast to get
the D interface, which enforces that contract.
Note that this is slightly different (and IMHO better) than the
classical programming by contract as implemented in Eiffel.
According to the LSP, D has a right to implement a "looser"
contract than B (looser pre-conditions and tighter
post-conditions); in Eiffel, if you have a reference to B, and
the object is actually a D, only the looser contract for D will
be enforced. In this implementation in C++, as long as you
access the object as a B, the full contract for B will be
enforced; in order to use the looser pre-conditions of D, you
must explicitly downcast.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]