Interface inheritance vs Implementation inheritance.

[S Perryman]

Robert Martin wrote:

It would also be trivial for an IDE to generate the delegation methods
for you, and no languages changes are required for that.

The big problem with delegation is correctness (safety specifically) :

type T
{
Delegate D ;

op() ;
}

T:p() = D.op() ;


Delegating service execution to some other object(s) D, would require
that D cannot be messed with (re-assigned, deleted etc) .

With heap-based object allocation, such guarantees become difficult.
With prog langs that can 'embed' a D into the representation of T (C++ ,
the "expanded" concept in Eiffel etc) , delegation is safer.


Regards,
Steven Perryman

 

[Silvio Bierman]

It would also be trivial for an IDE to generate the delegation methods
for you, and no languages changes are required for that.

IDEs should only generate code to save you some typing, like wrapping
code in a try/catch block.
Forwarding interface methods to an implementing object is not about
typing. It becomes nasty when you have no control over the interfaces
(JDBC/Servlet API wrappers are a good example as I mentioned somewhere
in this thread) and their development over time. If I want to write a
wrapper around such an interface I may just have to implement two or
three methods and simply forward the rest.

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.

IDEs generating code have very often been an excuse to create horrendous
constructs. Just look at the EJB specs for examples. Microsoft's MFC was
a prime candidate as well.

Regards,

Silvio Bierman

 

[Mike Schilling]

IDEs should only generate code to save you some typing, like
wrapping code in a try/catch block.
Forwarding interface methods to an implementing object is not about
typing. It becomes nasty when you have no control over the
interfaces (JDBC/Servlet API wrappers are a good example as I
mentioned somewhere in this thread) and their development over time.
If I want to write a wrapper around such an interface I may just
have to implement two or three methods and simply forward the rest.

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.

 

[Lew]

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

Ditto with abstract classes and new abstract methods.

 

[Mike Schilling]

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.

 

[Roger Lindsjö]

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.

IDEs generating code have very often been an excuse to create horrendous
constructs. Just look at the EJB specs for examples. Microsoft's MFC was
a prime candidate as well.

In that case you could use a build a Proxy which just intercepts the
methods you recognize.

However, trying to be "forward compatible" could still be a mess as not
only might the interface have new methods added to it, but the existing
methods could change their meaning which would probably make the
wrapping code invalid anyway.

 

[Silvio Bierman]

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.


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.

I am aware that a compiler trick is not enough to implement such a
feature. It would require auto-delegation logic at the JVM level which
makes it unlikely to ever happen. Looking at the hoops they jumped
through to sort-of implement generics without proper JVM support does
not give me much hope.

Regards,

Silvio

 

[Mike Schilling]

I am aware that a compiler trick is not enough to implement such a
feature. It would require auto-delegation logic at the JVM level
which
makes it unlikely to ever happen. Looking at the hoops they jumped
through to sort-of implement generics without proper JVM support
does
not give me much hope.

You misunderstand. What you see are the hoops they jumped through to
add generics without introducing either source or binary
incompatibility when a non-generic class is converted to a generic
one. You can argue about how important this goal was, but I've never
seen a superior solution to it.