[Exceptional C++ Style] Item 18 - Virtuality

[Kevlin Henney]

In message <31d4d63b0501071018125f0313 at mail.gmail.com>, Timothy Wright 
<tcw321 at gmail.com> writes
>
>I believe the Template Method is for known algorithms that can be
>split into multiple subalgorithms that could be implemented in
>different ways depending on need.
>
>class Method
>{
>public:
>    void DoSomething()
>    {
>           DoPart1();
>           DoPart2();
>           DoPart3();
>    }
>
>private:
>
>    virtual void  DoPart1();
>    virtual void DoPart2();
>     virtual void DoPart3();
>
>};
>
>NVI takes that to the extreme and says we don't have an algorithm we
>don't know what it is and it might have sub parts and might not.  But
>maybe we might need to add stuff in the base or split function into
>parts later so lets be prepared. The comments suggest that this is
>pure speculation and that it never really helps out in real world
>issues,  being too general.

NVI starts out by assuming that there are no functional additions that 
need to be made to a function, only operational ones, ie ones that don't 
actually affect the behaviour as revealed by returned or changed values. 
If you start doing functional changes, then you are dealing with a whole 
different problem altogether -- this is what Clemens Szyperski and 
others characterise as the semantic fragile base-class problem. So, the 
notion is that NVI should allow one to transparently introduce 
operational aspects, such as instrumention, non intrusively. There is no 
known sequence of steps that is being abstracted in advance, whereas in 
TM there is.

NVI is based on taking a call and wrapping it with a call in the belief 
that some operational requirement change in future will be accommodated 
by being to wrap the original underlying call with code that doesn't 
otherwise affect the functional behaviour of the program. Regardless of 
whether such optimism is actually reasonable or ever fulfilled (or is 
even the right way of doing it, which in most considered architectures 
it isn't: favour delegation/interception over inheritance) the reasoning 
is the reverse of what you leads you to TM. TM is motivated by the 
common phrasing having derived function overrides call their base class 
versions. A style that I used to view with some suspicion, but now view 
with immense suspicion and a likely sign that something needs to be 
fixed in a design. It is wiser to favour delegation over inheritance, a 
point that has been made in the OO community for quite some time, and a 
message that Herb also relays in his writing.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________