[Exceptional C++ Style] Item 18 - Virtuality

[Kevlin Henney]

In message <31d4d63b05010506386563ea54 at mail.gmail.com>, Timothy Wright 
<tcw321 at gmail.com> writes
>>
>> Yes indeed. The trouble is that Sutter writes on this so 
>>compellingly, that it feels almost churlish to argue against it. It 
>>actually convinced me for several hours when I first read this, but as 
>>Kevlin has already said, it's the Template Method aspect that rings 
>>the bell.
>> I wouldn't go so far as to say that NVI is never the right thing. 
>>There are some scenarios in languages other than C++ where NVI is a 
>>recognisable idiom.
>
>I have believed in Herb's comments and started implementing it in some
>code.  My thoughts were that I have code that is in constant flux.  I
>usually only have a couple of days if that to add features under the
>gun.  So if I had that extra indirection, maybe it would help me with
>hacking (oop's I mean refactoring) the code to get something done in a
>hurry.  But then I understand Kevlin's and others comments too.  It
>adds complexity.  And I have not seen any benefits yet of where I have
>implemented NVI

I think that many of the arguments for NVI -- not just from Herb -- rely 
more on faith and good intentions than either experience or sound 
theory. I struggle to recall examples I have seen where NVI would 
genuinely have addressed a design issue in a way that would not have 
been better addressed using another technique or adopting a different 
development approach.

The code-level practices that I have found to be useful in designing 
hierarchies are related to using interface classes and focusing on 
interface granularity. The process-level practices that I have found to 
be useful in designing hierarchies include test-driven development and 
joint design meetings. The return on investment from these is pretty 
quick in terms of testing, comprehension, build times, plasticity of 
implementation code, etc.

NVI appears to be a plaster (aka "band aid") -- and may legitimately 
have some role in an approach to architecture that is based on such a 
style of development -- rather than a genuinely pro-active, 
problem-solving design consideration.

The fact that NVI actively works against the reader of the class and the 
cues that programmers use in determining semantics from syntax stands as 
an obvious hurdle that it would need to compensate against if it were to 
be considered a general rather than a specific practice. The syntactic 
and cognitive baggage that it introduces to the simple idea of 
interfaces is generally inappropriate.

However, NVI is not a general or widespread practice, and fortunately it 
is unlikely that this situation will change much. That the practice is 
considered contentious is recognised by the dilution of the 
recommendation as it appeared in Herb and Andrei's C++ Coding Standards 
book, where it is prefixed with "Consider...", which dilutes it from a 
recommendation to a consideration.

>To expand something I think Kevlin has hinted on is that most
>programming books concentrate on language issues including Herb's
>books which I enjoy.  However, I am still at a loss on how to define a
>good design, regardless of language.  I measure it by coding something
>and see if it gives me trouble in the next few months.  Trouble in the
>sense of repeating mistakes, making many small corrections etc.  When
>do I know if I have a good design?  Then I get a new  requirement that
>blows away what I have done.  I thought that NVI was a good
>abstraction, if seen then the design is good but now I am not sure.

I have spent a lot of time reasoning about, examining and applying 
various design practices. It is not always easy to find something that 
is easy to measure to draw strong empirical conclusions, but sometimes 
case-based reasoning and specific experience-based examples are useful. 
It is also important to be able to situate design practices, establish 
their context and consequences. The notion that software development is 
inherently a learning process is important, and is why the notion of 
"good design" is a quality related to time and context rather than 
something more absolute.

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.

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
____________________________________________________________