[Exceptional C++ Style] Item 18 - Virtuality

Kevlin Henney kevlin at curbralan.com
Sat Jan 8 17:59:19 EST 2005


In message <003801c4f5ca$7a385e90$0a02a8c0 at bpxp>, Balog Pal 
<pasa at lib.hu> writes
>> One of my questions concerning NVI is precisely the question of 
>>appropriateness. I have been looking for an appropriate context for 
>>many  years, and have to find a solidly convincing one. As a 
>>problem-solving  design it seems somewhat speculative.
>
>I recall James Kanze writes his stuff DBC style and uses NVI like this.
>There functions are really close to TM, as the fuctions actually does 
>check invariants, preconditions, postconditions around the do-work 
>stuff.

Unfortunately, this is not a good way to apply DbC, and is perhaps one 
of the weaker justifications for NVI that has ever been raised. It 
suffers from a number of subtle flaws that are overlooked by many people 
who have basic knowledge of DbC and look no further into the fuller 
implications of the contract metaphor. For example, in the classic 
version of DbC that is based on pre- and postconditions, 
substitutability permits a derived class to weaken the precondition. 
This is not possible using straight NVI, and because of the nature of 
the steps this still does not properly qualify as TM.

In addition, introducing such a DbC framework is generally a waste of 
effort. Although it is based on good intentions, it is mostly ritual 
rather than time well invested. A set of unit tests will be a much 
clearer guide to the contract and the interface. Wading through an NVI 
version of a contract is more than a little tedious, especially when the 
notion of contract enforcement is based on assertions: all that 
infrastructure for something that isn't even compiled in. Although some 
people find comfort in the ritual, it is mostly syntactic and cognitive 
overhead for what it claims to deliver. The issue that it claims to 
address -- typically interface definition and conformance of 
implementation to interface -- is better addressed using other 
techniques. Code quality is generally achieved through slimming down 
rather than fattening up :->

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
____________________________________________________________



More information about the Effective-cpp mailing list