[Exceptional C++ Style] Item 18 - Virtuality

[Balog Pal]

> When presented in the abstract and outside of real systems, NVI tends to 
> have a stronger appeal than when it is considered in context and its 
> rationale is explored and exposed in greater detail. Among developers I 
> know and know of who have supported NVI in principle, when push has come 
> to shove few have been able to justify its general (or even specific) 
> application and even fewer find themselves applying it at all, so support 
> has come more in the form of lip service than practice.

Yeah, that is interesting how an idea that has good rationale on micro level 
is spoiled by exprapolation.

Even in the example for this item, there's a function

bool IsDone() const;

I honestly can't imagine any sane stuff that a base class could insert in 
the NVI version, and why the direct approach is bad.
Investing in flexibility is beneficial if the flexibility is needed (now or 
later). But it becomes similar to the discussion of the prevous item. There 
are parts of a program that are rock-solid.  Where you build on fundamental 
decisions, and keep those from changes. Or if you can't there will be a 
gross rework, either parts get replaced, or you *have* to change the 
interfaces with all the consequences of that.

Where the design makes clear that the base class has no clue altogether 
about what happens in the virtual function  implementation, having the 
nonvirtual plain forwarder serves no real purpose.

And it isn't free lunch. Any reader of the class will keep pondering on the 
purpose of the function. And its possible contents. At some level of 
maitainance it does introduce overhead. And it introduces an extra 
possibility for a bug -- what if someone "overrides" the nonvirtual instead 
of the virtual function by accident?  With an ounce of bad luck it can slip 
past the simple test cases too.

Duplicated functions mean additional negative redundancy -- and we shall not 
introduce it without getting some actual and harvestable benefit.