Adding delegation support for Java is a recurrent discussion on the technical mailing-lists. While it is hard to predict if it will eventually make it into the language, many proposals have already been advanced. Here is my contribution to this debate.
 

CONSTRAINTS

• Add functionalities that cannot be gained with the current status of the language
• Be easy to explain
• Be easy to implement
• Not break any existing code (use a new keyword as a last resort only)

RATIONALE

In Java, it's a bit trickier :

• You have to choose what will be inherited and what will be delegated
• And your object still won't "naturally" (not without some efforts) be both a Node and a Graphic : you won't be able to apply the substitution principle to it.

public class Node {
    public setName() {}
}

public class Graphic {
    public setX(int x) {}
    public setLabel(String name) {}
}

public class NodeGraphic extends Node {
    // delegation takes place here :
    public setX(int x) { _graphic.setX(x); }
    public setLabel(String name) { _graphic.setLabel(name); }

    Graphic _graphic;
}

Worse : if one day Graphic is improved, say with a function setBackground(), a simple recompilation won't be enough : you will have to add by hand the setBackground() function to your class. And this goes for all new functions, and deprecated ones. This is beginning to rhyme with nightmare, but it's part of the compromise Java makes with simplicity.
 

MY PROPOSAL

public interface IGraphic {
   // Defines what a Graphic is
};

public class NodeGraphic extends Node implements IGraphic(_graphic) {
    // ...
    IGraphic _graphic;
}

With this syntax, you are free to use whatever implementation of the interface IGraphic suits you best (in the constructor of NodeGraphic for example). Your class will never know about any concrete implementation of the interface it delegates to.

Of course, you can delegate to more than one attribute :

public class NodeGraphic extends Node
    implements IGraphic(_graphic), IComponent(_component) {
    // ...
       IGraphic _graphic;
    IComponent _component;
};
 

ALTERNATIVE SYNTAX

public class NodeGraphic extends Node implements IGraphic, IComponent {
    // ...
    IGraphic _graphic implements IGraphic;
    IComponent _component implements IComponent;
};

RESOLVING AMBIGUITIES

Static ambiguities

NodeGraphic ng = new NodeGraphic();
ng.clash();   // error : ambiguous

NodeGraphic ng = new NodeGraphic();
ng.IComponent.clash();

If ever the class NodeGraphic has its own clash() function, it is the one chosen. Delegated functions come second in the resolution of overridden methods. A typical implementation in such a case would be in class NodeGraphic :

public void clash() {
    _graphic.clash();
    _component.clash();
    // do your own clash stuff if any
}
 

Dynamic ambiguities

public interface IBase {
    public void f();
}

public interface IDerived extends IBase {
    public void g();
};

public interface IOther {
    public void g();
};

public class A implements IBase(_base), IOther(_other) {
    public IBase _base;     // public for clarity
    public IOther _other;
};

public class Base implements IBase {}
public class Derived implements IDerived {}
public class Other implements IOther {}

/* ... */

A a = new A();
a._base = new Base();
a.g();   // ok, not ambiguous
a._base = new Derived();
a.g();   // error, is it the g() from Other or Derived ?

Another way to solve this problem would be to throw a runtime exception, much like what happens when you try to store an object of a wrong type in an array (why this is not caught at runtime, I don't know). Instead of an ArrayStoreException, you would have some DelegationAmbiguityException.
 

VISIBILITY OF THE DELEGATED ATTRIBUTE

PROS AND CONS

This solution has very attractive properties :

• Simple to explain

 
• Simple to parse
Not much added to the existing syntax
 
• No new keyword

 
• Doesn't break existing code

 
• Simple code generation
Basically, node.setBackground() will be compiled to node._graphic.setBackground(), and there will be no code for setBackground() in the leaf class.
 
• True OO gain
The substitution principle can now apply : a NodeGraphic is both a Node and a Graphic, since we use the familiar 'implements' keyword.
 
• True coding gain
No need to delegate by hand all the operations. A simple recompilation will bring to your class all the functionalities that were added (or removed) in your ancestors.

--
Cedric Beust
 
 
 

THANKS

REFERENCES