July 13, 2007
Enterprise Systems: The New Bounce in Suns Step. Dont look now, but Sun Microsystems Inc. has a new bounce in its step.
From its recent...
More »
June 24, 2007
Jazoon'07. Jazoon'07 brings together experts and users of Java and open source technologies from all...
More »
|
 |
Code Tip: Statically Check Multiple Interfaces
You may think generics is all about avoiding casts in collections. However, I found a really good use for them the other day that's pretty useful.
Let's say you have a method which takes a List and does something with it.
void doSomething(List list) {
...
}
(In my code, it's actually List, but I'm trying to keep other generics out of this to motivate those of you still needing a good reason to learn them.)
In my case, I needed to iterate over the list in reverse order. Uh oh, that's going to be pretty expensive for some types of lists, and if I switch my implementation to for example a LinkedList in the future, I'd like to revisit this. Obviously, I could make my method the following:
void doSomething(ArrayList list) {
...
}
However, using specific implementation classes rather than interfaces is frowned upon, and besides, this needlessly prevents the method from being used with other random access list. On the other hand, I would like to state in some way that this method really wants to be able to access the list elements in random order.
java.util.RandomAccess to the rescue. Lists that provide random access implement this interface. But what do I put in my method signature? RandomAccess is not itself a List. I really want to specify multiple constraints on my parameter.
This is precisely what generic methods allow! The following method declaration will accomplish what I want:
void doSomething(T list) {
...
}
Here we're saying that my parameter T is a generic type, which satisfies multiple constraints: it both extends List and it implements RandomAccess! You can pass an ArrayList to the above method, but not a LinkedList!
Think hard about the constraints you add. In some cases, adding a RandomAccess constraint on a method is leaking implementation through to the client - it reveals something about the implementation behind the method signature that may change later. I find this most appropriate within implementation code.
Date: January 02, 2007
Category: Developers
More »
Others News
|