[Exceptional C++ Style] Item 18 - Virtuality

[Kevlin Henney]

In message 
<OF276A99DA.96BFDE3E-ON80256F7F.00330CDF-80256F7F.0033D2CD at sophos.com>, 
aung.oo at sophos.com writes
>
>The NVI approach has several benefits and no
>significant drawbacks.

Good summary. However, in terms of the content of what is being 
summarised I disagree strongly with this. It is pure supposition and I'm 
afraid that Herb and others have yet to demonstrate that this is a 
reasonable guideline either from first principles or in practice. As a 
pattern it is perhaps a dysfunctional one, but it would be mistaken to 
put it forward as a practice with the same pedigree as other practices.

If one takes the time to analyse where the supposed benefits are, it 
becomes clear that in all cases NVI is either an inferior solution 
compared to another (eg interception) or an architectural misconception. 
Of the frameworks that have used it, almost all would benefit from 
better alternative solutions -- it is worth noting that the main 
examples in the standard library (I/O streams and locales) are not 
exactly examplars of clear and appropriate design.

I have spent some time studying this, first in the early 1990s when I 
first became aware of it, and in more detail in recent times when the 
issue was raised on news groups and in some of Herb's articles. It was 
just over three years ago, IIRC, that I got into a discussion of this. 
At the time it was often presented as the Template Method, and I had 
serious issues with this because although there are structural 
similarities, the structure is significantly more constrained and the 
intent is quite different, two things that differentiate otherwise 
similar structures from one another in terms of being patterns.

This prompted Herb to fully adopt the term I believe he had in passing 
already been using, namely NVI. So, TM and NVI are certainly related in 
structure, but the detail of both structure and the forces being 
addressed are different.

I was also critical of what I felt was an overoptimistic application of 
the idea across all hierarchies to solve all ills. Having a 
problem-solving approach to things, and one informed by the style of 
thinking you find in well-structured patterns (not GOF, which includes 
fine patterns, but is not well structured), I wanted to focus on the 
context of applicability and the precise forces being addressed. In 
other words, how to document NVI as a pattern. Herb and I promised to 
look at this in more detail and see if we could come up with an article 
that balanced both our perspectives, and Herb made mention of this in 
one of his articles at the time.

Alas, this article never happened because the more I looked at what the 
context and forces were, the less applicable the solution appeared to 
be. I could always see a better design or see a deeper root cause that 
should be addressed. In most cases it is a solution looking for a 
problem. It sometimes takes a more architectural perspective to see why 
NVI is not a generally useful pattern. There is often too much focus on 
language features when we formulate advice, and not enough on 
understanding the real design issues. The only place that NVI has any 
home is in the middle layer of a well-structured class hierarchy, 
between the fully abstract roots and the fully concrete leaves. However, 
this means that the advice to make virtuals non-public is highly 
contextual rather than applicable to virtual functions in general, and 
it certainly contradicts the idea that the main interface should be NVI: 
interfaces should be fully abstract.

When you reason through the issues of class hierarchy design more 
carefully, it becomes clear why NVI does not play a first class role, 
and why its presence is normally an indicator of a problem rather than a 
solution. For those that are interested, I might as well plug my 
full-day tutorial preceding the main ACCU conference :-) I will be 
discussing the issues of class hierarchy design in some detail there, 
making reference to why NVI is not something that should be near the top 
of the toolbox.

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
____________________________________________________________