As usual, Blaine got me thinking; this time about writing legible code, in particular around Jakarta Commons Collections. His take, and I whole-heartedly agree, is that you should first think about how client code has to use your object. Blaine’s initial problem revolved around the ugly code he needed to use Jakarta Collections, as in:
Collection activeAccounts = CollectionUtils
.select(someAccounts, new Predicate() {
public boolean evaluate(Object each) {
return ((Account) each).isActive();
}
});
I initially liked his final solution,
// Account class
public static final Predicates BY = new Predicates();
// Class stuff...
static class Predicates {
public Predicate active() {
return new Predicate() {
public boolean evaluate(Object each) {
return ((Account) each).isActive();
}
};
}
}
// Client code
Collection activeAccounts = CollectionUtils
.select(someAccounts, Account.BY.active());
but it eventually dawned on me that the CollectionUtils dependency leaks through to the client. The problem is easily solved with static methods on the Account Class:
public static Collection selectActive(Collection someAccounts) {
return CollectionUtils
.select(someAccounts, new Predicate() {
public boolean evaluate(Object each) {
return ((Account) each).isActive();
}
});
}
// Client code
Collection active = Account.selectActive(someAccounts);
Even the word, static, makes me shudder but I couldn’t come up with a reason to prefer static inner classes static properties over static methods. I’ll compromise if it means I can hide more implementation from the client.
