Falling into the common developer trap
After a bit of time due to changing jobs and taking a holiday, I'm back into the Poker Game kata and working out the winning hand logic: how to handle identifying a pair beating a high card.
Unfortunately, I've done what I've seen is so common: started creating a "framework" rather than solving the problem. In this case, I've created a small collections framework:
public class Iterables {
public static <T, K> Map<K, Collection<T>> groupBy(Iterable<T> items, Action<T, K> keyMapper);
public static <T, V> Collection<V> select(Iterable<T> items, Action<T, V> selector);
}
Now you might say a couple of static methods does not a framework make, and of course, you're right. But this is a slippery slope. The obvious answer is to look around and see if I can simply use an existing library rather than building my own wheel.
My way it is
As it happens, I did think about this as I was working on the code and I'm familiar with Google Collections, now Guava. However, I'm going to stick, for now, with my own couple of methods. The simple reason being that this is meant to be a quick and simple application to solve the kata. It could then be deleted; although I'm going to leave it up on GitHub for prosperity. That being the case, including third party libraries just makes things a little more complicated. Do I use Maven or Ivy? Or just add the jar(s) to git?
Therefore, as long as it doesn't get too out of hand, I'll persist with just using out-of-the-box JDK only for the time being.
Others
It is interesting though to see how you miss certain libraries as you move between languages. Both C# and Scala have nice collections libraries which provide these kind of functional or higher-level methods, and although Java collections are rich and powerful, it would be nice to see some evolution here; perhaps when Java 7 introduces lambdas we may see this. Here's hoping.
