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

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

Daniel Weinreb wrote:
> In none of these cases did the need for multiple inheritance come up.
> We worked on this product for several years and just didn't need
> multiple inheritance anywhere.

Do I understand correctly that you mean one or both of the following:

* Many (or all) of your classes implemented only one Java interface
* Classes that implemented more than one Java interface were always able to
inherit the implementation for those multiple interfaces from a common base
class, thus avoiding the need to duplicate interface implementations.

What I'm saying is that either of the above constitute a limitation in
design that can, in some cases at least (I'd argue many cases), lead to
designs that aren't as well factored as they could be.  In essence, the
above implies that the constraints of implementation inheritance is
affecting the architecture of your interfaces.  But it is to avoid exactly
this that we want to separate interfaces from implementations in the first
place.

It sounds as though you may be claiming that good designs don't need to run
into this issue, that it's always possible to fit a design into a
single-implementation-inheritance approach, without having to duplicate any
implementations.  I agree it's possible - I did that kind of thing for many
years myself.  However, the fact that it's possible to avoid this issue
doesn't mean that avoiding it produces the best designs.

I'm suggesting that (a) the ability to decouple interfaces from
implementation, combined with (b) the ability to implement multiple distinct
interfaces on a class, provides factoring opportunities that don't exist
when you treat each class as essentially having a single interface.  This
moves towards more component-like systems, I think.  To exploit this fully,
though, you tend to run into the issue which Ken and others have raised, of
needing to duplicate interface implementations in some cases, across classes
which are unrelated by implementation inheritance.

I'm not suggesting that full-blown "old-style" multiple implementation
inheritance is the answer to this.  I think there are other alternatives to
support the mixin-like designs I'm talking about.  Some kind of automated
delegation approach can work - Microsoft's COM used such an approach, and
I've used something similar in dynamically-typed languages with good
results.  It was pointed out that Sather provided an alternative to this
which can also make sense.  I think Java's single-implementation-inheritance
combined with a complementary, secondary reuse mechanism of some kind might
work quite well, and enable a kind of design that perhaps isn't being fully
exploited currently, for practical reasons.

To put it much more broadly, the ability to reuse code in powerful but
manageable ways is a very mundane requirement with quite large practical
implications.  I don't think existing languages have really fully explored
the possibilities, and I'm quite convinced that Java hasn't.

Anton