RE: Java interface natural history was RE: "static" declaration

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

> > Certainly, many programs don't require the capabilities I'm
> > talking about, and many others that do can nevertheless get
> > away without them.
> > But I think there's a danger here, based on the way that
> > languages tend to limit thought.  Something that's factored
> > the Right Way for a language with single implementation
> > inheritance, and no explicit support for multiple interfaces,
> > might benefit enough from refactoring into a multiple
> > interface design
>
> Whoa, I'm confused.  You seem to be contrasting
> "language with single implementation inheritance'
> against "multiple interface design".  But multiple
> interfaces is multiple interface inheritance, not
> multiple implementation inheritance.  Anyway I'm
> not sure why we're talking about "no explicit support
> for multiple interfaces" since I think we both agree
> that multiple interfaces is very important.

Sorry, I was definitely trying to cram too many disparate points into one
paragraph.

The point I was originally making (actually agreeing with Ken) was that
having explicit support for multiple interfaces, as Java does, tends to
create a need (although not in all systems) for a kind of implementation
reuse which Java doesn't directly support.  This makes it tedious, at least,
if not downright unmanageable, to reuse interface implementations across
otherwise unrelated classes.  I was arguing that this is one of the reasons
that interfaces are not used to the fullest in Java - because there are
scenarios in which they would be appropriate, from the external interface
design perspective, but which would require extra work to implement, and
would make the system harder to maintain (due to duplicated code).

You've mentioned that in BPM, you didn't find the need for multiple
inheritance of implementation, and I'm not disputing that.  But different
systems have different kinds of complexity.  Thinking you were making a
broader claim, I argued that being restricted to single implementation
inheritance can lead to interface designs that are not as well-factored as
they could be - because it's natural (and pragmatic) to tend towards what's
easy to implement in the language, and Java makes reuse based on single
implementation inheritance easy.

Given a choice between a design which would require repeating the
implementation of an interface, and one which inherits that implementation
from a common base class, the latter choice seems cheaper and easier, at
least initially.  The problem with this is that choices regarding the
interface design are then being made based on constraints which the language
imposes on implementations.  I think that these kinds of choices, repeated
throughout a system, can quite easily lead to interface design factoring
which could otherwise be improved on.

If I'm correct, then Java's single implementation inheritance is, at least
in some cases, inhibiting full use of its explicit interface mechanism.
IIRC, you didn't seem to agree with that, in an earlier message.  The
problem I see with "proving" my point is that existing Java systems have all
been carefully designed to maximize their use of single implementation
inheritance, so we'd really have to take such a system and rework the design
to see whether it can be improved by greater decomposition of interfaces.
I've had some experiences which makes me think that it often is possible to
improve single-implementation-inheritance designs in this way - but in Java,
there may be some cost to this because of its implementation reuse
limitations.

When I said "no explicit support for multiple interfaces", I was thinking of
dynamically-typed languages which implicitly support multiple interfaces,
but don't acknowledge them explicitly in any way.  Languages like this end
up with a similar problem to the one I'm proposing for Java, but for a
somewhat different reason.  Heavy use of multiple interfaces tends to be
avoided in these languages, except in trivial cases with very small
interfaces, often single methods.  A big reason is that type enforcement in
these languages centers around the implementation class, and introducing and
using implicit types which don't correspond to classes is rather
impractical - they're difficult to pick out of the code, the compiler or
runtime environment isn't aware of them as entities, etc.

> Umm, this conversation may be getting too complicated for email...

Sorry if I've confused matters.  Your clarity of questioning is appreciated.

Aside from "multiple interfaces is very important", which we agree on, all
I'm really trying to say is that I don't think Java enables this approach to
be exploited as fully as it could be, and in some cases, should be; and that
this may not be obvious when looking at existing Java application designs.
As a result, I think the potential of multiple interfaces may be
underappreciated in the Java world; and even more so outside the Java world,
with some notable exceptions.

Anton