Composition/Delegation is a common pattern in object oriented software. There are a lot of different definitions floating around for both composition and delegation, but basically it amounts to this, as demonstrated in Java code:
class MyStringList implements List<String> {
private List<String> backingList;
public MyStringList(List<String> backingList) {
if (backingList == null) throw new NullPointerException();
this.backingList = backingList;
}
public String get(int i) { return backingList.get(i); }
public boolean isEmpty() { return backingList.isEmpty(); }
// ... lots of other methods like the ones above
public void add(String s) {
if (s == null || s.length() == 0)
throw new IllegalArgumentException();
backingList.add(s);
}
// and some more slightly modified methods to complete List
}
So MyStringList is composed of backingList and it delegates most of its methods to it. Furthermore, in this case it is using backingList to implement the interface List
class MyStringList extends ArrayList<String> {
public MyStringList() {}
public void add(String s) {
if (s == null || s.length() == 0)
throw new IllegalArgumentException();
super.add(s);
}
// do something for the other add methods as required...
}
That's a lot less typing. It's also strongly coupled to ArrayList
class MyStringList implements List<String> {
private delegate List<String> backingList;
public MyStringList(List<String< backingList) {
if (backingList == null) throw new NullPointerException();
this.backingList = backingList;
}
public void add(String s) {
if (s == null || s.length() == 0)
throw new IllegalArgumentException();
backingList.add(s);
}
// and some more slightly modified methods to complete List
}
The delegate keyword tells the compiler that any methods from List
Friday, August 17, 2007
Syntactic Sugar for Composition/Delegation
Posted by Erik Engbrecht at 12:36 PM
Labels: Java, programming, Python, Scala
Subscribe to:
Post Comments (Atom)
1 comment:
I'd like to see some form of this in Java (and Scala, of course ;-) IANACW but it appears that the benefit would be large compared to the level of effort to implement.
I do think that the Scala-like approach of class-level parameters would make this more readable than the Java-like syntax in your specimen code. Something resembling:
public class Foo implements List(delegate List<String> myList) ... {
...
}
would provide these benefits:
* ties more closely to the idea of implementing an interface as a class-level concept,
* emphasizes the delegate's special role, e.g. could then be automatically instantiated by the constructor,
* eliminates the need to search for the delegate (e.g. if someone wrote your posted example using the instance-variables-at-the-end style),
* potentially allows a class to have distinct delegates for non-overlapping interfaces, clearly marking which delegate is in each role.
At any rate, given the widely-discussed benefits of delegation, I think it's time to consider language support in some form. Thanks for raising the issue!
Post a Comment