I’m writing a method in Java:
List<Foo> computeFooList(/* arguments */)
{
/* snip */
}
I’d like to write a second method with exactly the same logic, but a different return type:
List<String> computeStringList(/* same arguments */)
{
/* snip */
}
I’m trying to figure out a non-hackish way to minimize the amount of repeated code between the two methods. The only logical difference between the two is that, when adding an object to the list that’s returned, the first method adds the acutal Foo:
List<Foo> computeFooList(/* arguments */)
{
List<Foo> toReturn = ...
...
for (Foo foo : /* some other list of Foo */)
{
if (/* some condition */)
{
toReturn.add(foo);
}
}
...
return toReturn;
}
and the second adds a String representation of the Foo:
List<String> computeStringList(/* same arguments */)
{
List<String> toReturn = ...
...
for (Foo foo : /* some other list of Foo */)
{
if (/* some condition */)
{
toReturn.add(foo.toString());
}
}
...
}
In reality, it’s not quite that simple. I don’t want to add a Foo to toReturn unless I’m absolutely sure it belongs there. As a result, that decision is made per-foo using helper functions. With two different versions of the methods, I’d need different versions of the helper functions as well – in the end, I’d be writing two sets of nigh-identical methods, but for one little generic type.
Can I write a single method which contains all of the decision-making logic, but can generate either a List<Foo> or a List<String>? Is it possible to do this without using raw List types (bad practice in generics land!) or wildcard List<?> types? I imagine an implementation that looks something like this:
List<Foo> computeFooList(/* args */)
{
return computeEitherList(/* args */, Foo.class);
}
List<String> computeStringList(/* args */)
{
return computeEitherList(/* args */, String.class);
}
private List<???> computeEitherList(/* args */, Class<?> whichType)
{
/* snip */
}
Is there any nice, elegant way to do this? I’ve been playing around with generic methods, but I can’t see a way to do this. Even mucking about with reflection hasn’t gotten me anywhere (maybe I need something like TypeToken? …eww).
Can’t you externalize transformation logic into a separate strategy (such as Guava’s
Function<F, T>):computeFooList:
computeStringList: