Question about grouping or separating functions / methods that are alike

Question

I'll take a real example I have to implement in a program I'm coding:

I have a database that has the score of every game bowled in the past three years in a bowling center. With a GUI, you can choose to either search for the best score on each lane, search for the best score between two dates, for the best score for each week, etc.

I'm wondering what the best way to implement this is. Should I code something like this:

public Vector<Scores> grabMaxScores(sortType, param1, param2)
{
    if(sortType.equals("By lane"))
        ...
    else if(sortType.equals("Between given dates")
        ...
}

Or is it more appropriate to code different methods for each type and call the correct one in the listener?

public Vector<Scores> grabMaxScoresBetweenDates(startDate, endDate)
{
    ...
}

public Vector<Scores> grabMaxScoresByLane(minLane, maxLane)
{
    ...
}

I'm not necessarily asking for this particular problem, it's just a question I find asking myself often when I'm coding multiple methods that are alike where the principle is the same, but the parameters are different.

I can see there are good reasons to use each of them, but I want to know if there is a "more correct" or standard way of coding this.

Answer 1

In my personal opinion, I would prefer your second option over the first. This is because you have the opportunity to be precise about things like the types of the parameters. For example, minLane and maxLane may just be integers, but startDate and endDate could very well be Date objects. It's often nicer if you can actually specify what you expect, as it reduces the need for such things as casting and range checks, etc. Also, I would find it more readable, as the function names just say what you are trying to do.

However, I may have an alternative idea, which is kind of a variation on your first example (I actually got this inspiration from Java's Comparator, in case you're familiar with that). Rather than pass a string as the first argument, pass some sort of Selector object. Selector would be the name of a class or a interface, which would look something like so (in Java):

interface Selector {
    public void select(Score next);
    public Score getBest( );
}

If the select method "likes" the value of next which is given to it, it can store the value for later. If it doesn't like it, it can simply discard it, and keep whatever value it already has. After all the data is processed, the best value will be left over, and can be requested by calling getBest. Of course, you can alter the interface to suit your particular needs (e.g. it seems like you might be expecting more than one value to be retrieved. Also, generics might help a lot as well).

The reason I like this idea is that now your function is very general purpose. In order to add new functionality, you don't need to add functions, and you don't need to modify any functions you already have. Instead, the user of your code can simply define their own implementation of Selector as they see fit. This allows your code to be far more compositional, which makes it easier to use. The only inconvenience is the need to define implementations of Selector, though, you could also provide several default ones.