Mike Schilling wrote:
Robert Martin wrote:
True, but you DO have to write all the delegating functions. Ick.
Why should I have to write a bunch of brain-dead delegation
functions
every time I want to reuse some nice piece of implementation.
It would be trivial to add language feature that did
composition-and-delegation for you. It might look like this:
class MyContainer composes SomeContainer {
...
}
This would create a hidden instance variable for SomeContainer,
and
automatically write delegation functions in MyContainer.
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.
That's true of any interface that adds methods. Classes that formerly