RE: Jonathan Rees on OO

["Anton van Straaten" <address@hidden>]

Dan Weinreb wrote:
> Still, sometimes my colleagues get a little bit annoyed at me when I
> create an interface for something, and then it turns out that it's
> convenient to have an abstract base class with some useful little
> shared implementation, and in fact every concrete class that
> implements the interface does indeed extend that base class.  They
> come to me and say, why bother with the interface?  They say, having
> both the interface and the base class is verbose and redundant.  I can
> see what they mean, but I still think that using the interface is
> the Right Thing in some sense.

I agree, it is the right thing.  The problems created by conflating things -
in this case, the interface/type and its implementation - tend to be much
worse than the "problem" of verbosity or a bit of redundancy.

If you omit the interface, and it turns out later that there's an
implementation which doesn't need any of the code in your base class, then
you either have to refactor, potentially affecting a lot of client code; or
create a misleading inheritance relationship in which a subclass overrides
everything that its parent defines; or create a whole new interface or class
that perhaps varies just slightly from the original one, which will damage
the genericity of your code, as you then have to reimplement things dealing
with that interface which otherwise might have shared an implementation.
Over a large code base that grows over many years, this is the kind of thing
that leads to problems.

Besides, in Java I find that typically, an abstract base class of the kind
you describe doesn't need to implement all the methods of the interface, so
there's not as much redundancy as all that, if you omit the methods that it
doesn't implement.

> (You could sort of imagine a Java-variant that allowed interfaces to
> be used as types but didn't allow classes to be used as types.  Then
> you'd really have to use interfaces in the above case.  But I don't
> imagine a lot of people would like such a change; I don't even think I
> would...)

If it were designed with conciseness in mind, I don't think it would have to
be that onerous.  Think of C++: except for classes that you define entirely
in a header file, you pretty much always have to "declare" the class
separately from its implementation.  Of course, there's a reason for that in
C++, but I don't think that aspect of the language is particularly onerous -
and it can be mitigated with tools.  The trouble is that Java developers
have been spoiled by not having to do this.

Here's an idea that would satisfy me - to use the Java example, allow
something like this:

	abstract class foo interface ifoo


...which would simultaneously declare a class foo, as well as an interface
ifoo, with the same signature as the class.  This way, if the class and the
interface later need to be separated, it could be done without impacting any
client code; and there's no redundancy or verbosity.

Given a feature like this, you could institute an [optional] feature that
didn't allow classes as types, with very little overhead.  Unless it was in
a new language, it would have to be optional, because otherwise it would
break existing code something horrible...

Anton