Re: Interface freeloading on a superclass - is it good practice?

> Well, it's really not a purely academic discussion. Here is an excerpt
> from the actual program:
>
> public interface IToolButton{
> boolean isSelected();

<snip>

> boolean isDoubleClick();
>
> }
>
> An IToolButton CAN be implemented by a lightweight java.awt.Component,
> but it can also be implemented by something else, for instance by
> interfacing to some JavaScript code. The rest of the program treats
> any implementation solely as an IToolButton (good practice!), and if I
> implement it NOT using a java.awt.Component, I will have to supply all
> the methods, most of which come free in Component.

It does look a bit like you're trying hard to bend reality to fit some
strange "clever" scheme which may be more trouble than it's worth, in the
long run. As with many apparently-clever schemes, this one smells of
potential problems: say that Sun, in their infinite wisdom, decide that one
or more of the methods you've "hijacked" in your interface need
reimplementing, possibly with their functionality subtly changed. Suddenly
your clever interface scheme breaks... and you're desperately forced to
patch the new AWT or Swing component (by overriding the newly "misbehaving"
methods) to behave the way your interface expects a subset of AWT/Swing
component methods to behave. These patches may be impossible to write, in
which case you'll be forced to rename some of your interface methods, which
in turn will force you to implement those methods you previously believed to
come "for free" in Component, etc..

So all in all, unless my prediction of trouble ahead is flawed, I think you
need to go back to the drawing board on this one.,..


.