Name: vi73552 Date: 07/06/99


Extensive use of interfaces in applications and APIs often leads to more complex class implementations and code bloat and duplication simply because of the number of methods which have to be specified as part of delegating to one or more "support" objects.

Take the InfoBus as an example. It would be nice if light weight objects (e.g. simple widgets and data objects) could be made to participate in interactions with an InfoBus. Unfortunately, the costs of implementing and maintaining several classes in this way are high by virtue of the sheer number of interfaces which have to be implemented.
Even if the implementation involves simple delegation to support objects, the interface implementations often end up conceiling the functionality which is otherwise central to the class.

Assuming multiple implementation inheritance is out of the question, one possibility might be to simple name an object instance as the implementor of a particular interface e.g.

class X extends Y implements I, J
{
  support I with new IImplementation();
  support J with new JImplementation();
  :
}

Which is effectively shorthand for:

class X extends Y implements I, J
{

  /* Implement I */
  public void method1() {}
  public void method2() {}
  public void method3() {}
  :

  /* Implement J */
  public void method4() {}
  public void method5() {}
  public void method6() {}
  :
}

This suggestion clearly does not address all the issues which would arise from such an approach, but I suspect something along these lines could lead to more readable code with a good deal less duplication.
(Review ID: 85222)
======================================================================