Program to an interface, not an implementation

[Eric Brunel]

Egbert Bouwman wrote:
> All your comments are crystal clear. Thanks.
> 
> My next problem is on nearly the same page (17) of the GoF book:
> class versus interface (== type) inheritance, but in the python context.
> 
> "In C++ and Eiffel inheritance means both interface and implementation
> inheritance" and
> "in Smalltalk inheritance means just implementation inheritance".
> I don't know any of these languages.
> 
> Now in my simplistic worldview, if you inherit from a class,
> you inherit everything, implementation and interface,
> because the implementation defines the interface as well.
> Even if all methods of the superclass only contain 'pass'.
> But I may be wrong.

I know C++ and I looked at SmallTalk a bit, and it seems the line between 
"implementation + interface" and "implementation only" inheritance is very 
thin... Apparently, it's quite directly related to strong typing and 
declarations. "Interface", in this context, seems to describe what's 
declared. So, as you noted in the beginning of your post, an "interface" is 
considered as a declared type. Since SmallTalk claims to have no types at 
all (which is also the case with Python...), they claim not to have such 
thing as an "interface", so obviously they cannot inherit it...

In fact, I don't see the point in this: as you noted, when a class inherits 
from another, it inherits everything, implementation and interface. So in 
practice, it's not really significant. As I understand it, the only 
practical consequence of this distinction *may* be in the following case:

class A:
  def m(self, i):
    pass
class B(A):
  def m(self, i, j):
    pass

In Python or SmallTalk, the preceding code is completely valid, so one 
could say that the "interface" of class A was not inherited by class B, 
since its method m has a different signature than A's method m.

Trying to do the same thing in interface-inheriting languages would not 
have the same effect at all: it would either be forbidden, or even have 
stranger consequences. In C++ or Java, it would declare a *second* method, 
also called m, that would be distinguished from the inherited one by its 
number of parameters or their type:

public class A {
  public int m(int i) {
    ...
  }
}
public class B inherits A {
  public int m(int i, int j) {
    ...
  }
}
...
o = new B();
o.m(1)      // Calls A.m
o.m(1, 2)   // Calls B.m

So, as you see, you probably can live without knowing anything about all 
this and still be able to do great stuff with whatever language you like 
:-).

However, if anybody knows a bit more than me about implementation/interface 
inheritance, I'd be glad to learn (I happen to teach OO sometimes and I'd 
like to be able to answer this question precisely if it ever gets answered 
to me ;-).
-- 
- Eric Brunel <eric.brunel at pragmadev.com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com