Refactor of Collector interface
Brian Goetz
brian.goetz at oracle.com
Fri Feb 8 07:25:05 PST 2013
FYI: In a recent refactoring, I changed:
public interface Collector<T, R> {
R makeResult();
void accumulate(R result, T value);
R combine(R result, R other);
}
to
public interface Collector<T, R> {
Supplier<R> resultSupplier();
BiConsumer<R, T> accumulator();
BinaryOperator<R> combiner();
}
Basically, this is a refactoring from typical interface to
tuple-of-lambdas. What I found was that there was a lot of adaptation
going on, where something would start out as a lambda, we'd wrap it with
a Collector whose method invoked the lambda, then take a method
reference to that wrapping method and then later wrap that with another
Collector, etc. By keeping access to the functions directly, the
Collectors code got simpler and less wrappy, since a lot of functions
could just be passed right through without wrapping. And a lot of
stupid adapter classes went away.
While clearly we don't want all interfaces to evolve this way, this is
one where *all* the many layers of manipulations are effectively
function composition, and exposing the function-ness made that cleaner
and more performant. So while I don't feel completely super-great about
it, I think its enough of a win to keep.
More information about the lambda-libs-spec-experts
mailing list