[Zope3-dev] Re: Interface Inheritance

guttner@fit.vutbr.cz guttner@fit.vutbr.cz
Thu, 13 Mar 2003 13:19:47 +0100 (CET)


>> This is probably a matter of design principles.  In general, I go for 
>> the Liskov substitutability principle; that is, I should be able to use 
>> a subclass where the superclass is acceptable.  This implies, in other 
>> words, that failing to implement a superclass' interfaces is a no-no.  
>
>I think this is a reasonable principal that is rarely followed.
>It would certainly discourage the use of inheritence purely
>for implementation sharing.

There is a difference between subclassing and reusing implementation. Many 
languages only support one of them so there is a bit of confusion. Inheritance 
says "X is a kind of Y" while reusability says "X is based on Y".

Consider an example: Dog is an animal and and animal moves -> a dog moves. 
Inheritance. But (blindly supposing that Darwin's theory really works): Man 
evolved from apes and apes have fur -> man has fur.

What I'm trying to say is that inheritance should be used in places where you 
work with a specialized subset of superclass instances that can do something 
more. Evolution (the second kind) is more like versioning, and it basically 
means use the same code as something else and don't care about contracts. I 
know this is a bit theoretical but at least it helps me think about inheritance 
the right way...

>I think Stroustrup would think along those lines.  In C++, virtual 
>methods are safe to override, while non-virtual methods aren't 
>necessarily safe (you can do it, but you might not get what you 
>expected).  And Java has "final" methods (which you can't override). 
>Python has no way to declare anything similar.

I'd be careful here. Having virtual and nonvirtual methods is a decision that 
has to be made in compiled systems for the sake of speed, while sacrificing 
flexibility. "Normal" methods are hardwired by the compiler while virtual 
methods have jump tables. BTW, it's one of the biggest disadvantages of 
compiled systems, because they lose flexibility that for example can be kept in 
Python. I think that only Java "final" methods are intentionally related to 
security.