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).
To avoid the problem of duplicated bugs, never reuse code by copying and pasting existing code fragments. Instead, put it in a method if it is not already in one, so that you can call it the second time that you need it.
A dry run is the process of a programmer manually working through their code to trace the value of variables. There is no software involved in this process. Traditionally, a dry run would involve a print out of the code.
DRY stands for Don't Repeat Yourself and the principle is that there should only ever be one copy of any important piece of information. The reason for this principle is that one copy is much easier to maintain than multiple copies; if the information needs to be changed, there is only one place to change it.
Can't you externalize transformation logic into a separate strategy (such as Guava's Function<F, T>
):
public <T> List<T> computeList(/* arguments */, Function<? super Foo, T> f) {
List<T> toReturn = ... ...
for (Foo foo : /* some other list of Foo */) {
if (/* some condition */) {
toReturn.add(f.apply(foo));
}
}
return toReturn;
}
computeFooList:
computeList(..., Functions.identity());
computeStringList:
computeList(..., Functions.toStringFunction());
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With