Re: Interface inheritance vs Implementation inheritance.

From:

"Mike Schilling" <mscottschilling@hotmail.com>

Newsgroups:

comp.object,comp.lang.java.programmer

Date:

Thu, 21 Feb 2008 08:26:24 -0800

Message-ID:

<RChvj.5507$Mw.3771@nlpi068.nbdc.sbc.com>

"Lew" <lew@lewscanon.com> wrote in message
news:QsSdnRC6f80PBSDanZ2dnUVZ_i2dnZ2d@comcast.com...

Mike Schilling wrote:

"Silvio Bierman" <sbierman@jambo-software.com> wrote in message

Having the IDE generate my "forward the rest" code will result in
a class that only works with a specific version of the interface.
If you own the interface this is already a maintenance nightmare
requiring very advanced refactoring support to be manageable but
if it is a public interface that evolves (usually this means new
methods are added in time) your code gets broken in time
automatically.

That's true of any interface that adds methods. Classes that
formerly implemented it successfully will fail to compile.

And given how the JVM and bytecode work, it would, unless I'm missing
something, be equally true of a Java language feature that performed
delegation. That is, the feature would generate bytecode to do the
forwarding (possibly being clever enough not to generate forwarding
methods for methods that are hand-coded), not adjust its beahcior at
run-time according to the version of the interface currently loaded.

Ditto with abstract classes and new abstract methods.

Yup. One of the advantages of defining an abstract class that clients
can extend vs.defining an interface for them to implement, is that you
can later add new methods by giving them default implementations.
Obviously this won't always work, and there are disadvantages to
abstract classes as well, but it's something to consider when
designing a framework.