[Exceptional C++ Style] Item 18 - Virtuality

[Kevlin Henney]

In message <3E28BEE03F7CD3118E540008C7F35FF603C2D264 at NMEX01>, "Hammond, 
Peter" <peter.hammond at amsjv.com> writes
>
>Sorry to come late to the discusion, and overlap the next item. At first I
>thought I agreed with the original guideline, but now I'm not so sure. I
>think what I agree with is using Template Method, but I'm slightly confused
>still. I'm not sure that I see the distinction between NVI and Template
>Method.

The intent of Template Method is given in GoF as follows:

"Define the skeleton of an algorithm in an operation, deferring some 
steps to subclasses. Template Method lets subclasses redefine certain 
steps of an algorithm without changing the algorithm's structure."

Regardless of one's opinion of NVI, it is clear, from reading any of 
Herb's material on the topic, that the goal is different. There is no 
skeletal algorithm and there is one step that is delegated. What they 
have in common is this self-delegation/down-call structure, but 
structure is not the same as intent, and in the case of NVI the 
structure is more constrained and differently motivated. It is possible 
to refactor an NVI implementation to a TM one should the need arise, but 
the patterns are still distinct.

>There are certainly many cases where pure abstract interfaces (I think that
>is the right term, a class with only pure virtual fuctions) are useful in
>promoting encapsulation. But an abstract base class with implementation does
>not seem like an abomination to me, in the right circumstances - these being
>mainly that there are no package boundaries (for some value of "package") to
>enforce separation across. If we consider always starting from the three
>layer approach, sometimes we will remove the middle man, but perhaps
>sometimes we remove the pure abstract interface, if that is seen to be not
>adding anything?

It is unlikely that removing the pure abstract class would be the right 
choice once it had been introduced. The only case I can think of would 
be if the hierarchy itself was being retired, leaving behind a specific 
concrete class in its place.

>And then we end up at NVI. It seems that, like any other
>guideline, there is an unspoken "when it is appropriate" there. Perhaps the
>guideline should be more like the last guideline in this item: "Make
>interfaces either nonvirtual or pure virtual".

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.

The recommendation that makes the most architectural difference and has 
the most solid track record is to favour pure roots to hierarchies.

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
____________________________________________________________