[Qt-interest] Non-Virtual Interface Idiom

[Oliver.Knoll at comit.ch]

On 2010-12-20 Thiago Thiago Macieira wrote:

> On Monday, 20 de December de 2010 10:34:10 Oliver.Knoll at comit.ch wrote:
>> I think Herb Sutter did not understand the point of interfaces: he 
>> mixes implementation with interfaces. When I talk about "interfaces" 
>> I think "Java interfaces", and in C++ that renders to pure virtual 
>> classes (in my understanding of "interfaces").
>> ...
> Considering who Herb Sutter is, I wouldn't say he "did not understand 
> the point of interfaces". 

I have to admit I had to google up his name - he /does/ seem to have a solid C++ background, to say at least ;)

> There's no keyword "interface" in C++ and 
> Java concepts have absolutely no relevance to us and him.

... that is why I added the "when I talk about interfaces" clause ;) I totally agree that I mistakenly geared the discussion towards "Java interfaces", and I know that there is no such 1:1 equivalent in C++ (pure virtual classes are the closest construct to that).

> An interface is just the contract between the class and its users.

Totally agree.

> It's the API, both the public one and the protected and private one.
> In that sense, he has made no confusion and your argument that they 
> have to be public pure virtual doesn't apply.

Sure.

> However, in the end, I don't agree with his argument. 

Neither do I. Even in the general sense of "interface" I don't see why it should be a problem - even conceptually or in any other way - that a class both says "This is what I do and this [the virtual part] is how you can extend/overwrite" me. And that seems to be his main argument, what he calls the "simultaneously part" of it.

> There are many 
> legitimate cases for having public virtual methods. There are also 
> many cases where his recommendation makes sense, see:
> 
> 	http://doc.trolltech.com/3.3/qiodevice.html#writeBlock vs
> 	http://doc.qt.nokia.com/latest/qiodevice.html#write
> 	http://doc.qt.nokia.com/latest/qiodevice.html#writeData

I absolutely agree! The Template Pattern is a very useful one! (But still, that does not justify to /always/ use it!)

I remember one of my last lectures at university where - after may lessons how great OO would be - we were thaught that "inheritance is evil". I remember one simple example of a given base class which by itself was absolutely correct. Also the derived class was absolutely "correct" in how it extended the base class. Then some easy "optimizations" where introduced into the base class - basically some result was "cached", but not changing the interface at all! - and the whole thing broke! It was like a proof had been given that 1 + 1 = 3! The whole code example was on an A4 paper (which unfortunately was lost during my "post-university cleanup time"), but the keywords I remember were "fragile base class problem" and "jojo effect" (because the child class would call a super method which would call another base class method, but which was overridden again, so the "point of execution" would go up and down the class hierarchy, which is very hard to analyse statically).

Summary: despite the promise that OO would favour data encapsulation you actually HAVE to know the actual implementation of a given base class before extending from it - or rather, try to avoid extending classes, more often composition is more suitable. Or "real interfaces" ;) Or do a "planned extensibility" like with the "Template Pattern", where the base class controls the order in which e.g. data is read, as in the example with qiodevice. But it is very easy to break functionality when deriving, as I just learnt bitterly again when subclassing from QGraphicsScene and overriding (or rather NOT overriding) dragMoveEvent, also refer to http://www.qtcentre.org/threads/8022-QGraphicsScene-doesn-t-accept-Drops ("It's because QGraphicsScene provides a default implementation of dragMoveEvent that checks if there are items on the scene under the cursor that accept drop events." -> if you don't override this method, your scene won't accept drops onto "empty space"!).


Cheers, Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22