Re: Template Method in multi leveled inheritence
Hendrik Schober wrote:
Victor Bazarov wrote:
If you can elaborate on the
pattern's losing "his meaning", do. If not, well, don't.
I'm not sure what you expect. The point of the pattern is
that the base class calls the derived class, freeing the
derived class' implementer of worrying whether to call the
base class' implementation of some virtual function before,
after, or amidst the derived class' algorithm. But in the
situation the OP describes, the implementer of C is back
at having to worry. I found the OP having explained the
situation clearly and don't see anything I could add.
[..]
Well, that's too bad. The pattern is not about freeing the implementer
from worrying whether to call the base class' implementation for
whatever the implementation may require, or not. It's about providing
the algorithm (sequence) and letting the derived class supply only
pieces, according to the requirements of the algorithm.
In the case of the OP, if the entire algorithm consists of the only call
to the 'initialise' function, then, in the hierarchy
class A {
public:
void init() { /// algorithm
initialise(); /// piece provided by the [most-]derived class
}
protected:
virtual void initialise() = 0;
};
class B : public A {
protected:
virtual void initialise() { /* whatever */ }
};
class C : public B {
protected:
virtual void initialise() { B::initialise(); /* whatever else */ }
};
the act of calling B::initialise() as the first step in C::initialise is
an implementation detail and AFAIUI does *not* violate any rules or the
intentions of the pattern.
If class 'C' is intended to be the "piece supplier" to 'A's algorithm,
the inheritance of 'C' from 'B' has nothing to do with it. If you look
at the pattern, its description involves two parts, the algorithm and
the components of the algorithm. Here they are provided by the same
class (which is perfectly fine), 'A'. 'B' derives from 'A' and provides
the piece[s] (the final overrider for 'initialise' member). If the user
wants to do something similar, they should derive from 'A', not from
'B'. That's how the pattern is actually defined.
'C' derives from 'B' - *why*? The OP did not say. For all I could
gather, it's something the users of 'B' can do, and the OP had no
control over it. So, the OP worries that because he didn't provide
enough protection, the user can do something wrong. So? The user will
always figure out a way to make a mistake or to misuse the classes they
are given. And we here cannot hold every poster's hand and keep
repeating, "Document your classes carefully, provide as much information
as possible to allow user to see the light, and stop worrying about the
user's screw-ups, you're not responsible..." What can be done
programmatically? Nothing, really, except denying the user the ability
to derive from 'B'...
There are two other newsgroups where the discussion on patterns is
better placed: comp.software.patterns and comp.object. I don't want to
appear unaccommodating, but if the OP or you have some doubts whether
allowing C::initialise to call B::initialise would somehow invalidate
the pattern, they should probably be cleared there, by experts in the field.
If there is a seeming collision between the rules of the language and
the pattern itself, it's probably true. But keep in mind that some
patterns (like the Template Method here) are somewhat simplistic and not
supposed to answer all questions or be the panacea for design problems
or protection against users' ignorance.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask