[Qt-interest] Non-Virtual Interface Idiom

[Konrad Rosenbaum]

On Sunday 19 December 2010, Piotr Dobrogost wrote:
> One of design rules made popular by Herb Sutter is Non-Virtual Interface
> Idiom explained in the article "Virtuality" in C/C++ Users Journal,
> 19(9), September 2001 (http://www.gotw.ca/publications/mill18.htm),
> which can be summarized in the guideline "Prefer to make interfaces
> nonvirtual, using Template Method." In many places design of Qt classes
> does not obey this rule. Is there any rationale for this?

Because he is contradicting standard design practices.

He is duplicating functions purely for the sake of fixing a broken interface 
design that should be completely overhauled instead. His guideline #1 only 
makes sense if two specific points apply: 1) you have a broken interface and 
too much code that would be affected by refactoring it, and 2) you have full 
control over all the code in case you do need to change something. If 1) 
does not apply you can refactor without much pain, if 2) does not apply in 
face of a broken design you are screwed anyway and need to do a fresh start.

Guideline 2 also only applies to the exact same broken code.

A better guideline would be: never design how something is done, but what is 
done - i.e. each method defines a clear, self-contained and complete 
operation, there must be no need to call any other method in any specific 
order (before or after any method) for the object to be left in a consistent 
state.

His choice of Process/DoProcess as method names is exemplary for what you 
should not do. On the other hand a method paintGadget(...) would be self 
contained and complete - there is (almost) no way to misinterpret it and it 
comes with the assurance that everything necessary to paint your Gadget on 
your Widget is done.

This is the way Qt is designed and it completely removes the need for fixing 
a broken design.

Guideline 3 contradicts 1+2 - if the first two were sound, then #3 would not 
be necessary. It breaks down completely if the one who needs to change the 
protection level cannot (or is forbidden to) change the code where it needs 
to be changed.

Guideline 4 just drags out arguments that match some very specific 
constructed cases. The rule should instead read: if there is the slightest 
chance (if it is an interface there usually is) that the class will be 
derived from: make the destructor virtual, the remainder will follow from 
your design.


In short: the methodology shown in the article can only be applied to 
projects that are under a very tight schedule, fighting against broken 
design and incapable programmers. It limits the damage until you have a 
chance to completely redo the project the proper way.



	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101220/3326b6fb/attachment.bin