Interface Implementation: A parameter I don't need

Question

Pseudo-Code

interface IPagingInfo
{
    int CurrentPageNo { get; }
    int RowsPerPage { get; }
    ...
}

interface ResultsRetriver
{
    ResultRows GetResults(IPagingInfo pagingInfo);
}


class ANewResultsRetriver : ResultsRetriver
{
    ResultRows GetResults(IPagingInfo pagingInfo)
    {
        // TODO: Retrieve and return all results, ignore pagingInfo.
    }
}

Explanation

interface ResultsRetriver has existed since as long as we know time. There are many implementations of ResultsRetriver all happily working in the system. The new programmer comes in and is tasked with writing the ANewResultsRetriver. His results retriever however is different in that it does not have a concept of paging, it must always return all results.

The programmer feels the person who wrote interface ResultsRetriver should have provided a version of the call without the paging parameter for cases such as this, where the parameter is not required. Now he wants to add it in, a GetResults().

A colleague suggests that it's okay to not use the pagingInfo parameter in this special case, but what if the caller sends in valid pagingInfo expecting results to conform to the supplied pagingInfo? Then ignoring the callers request may not be prudent. So the colleague also suggests we throw a PagingNotSupportedException() to alert the caller if a valid pagingInfo is supplied.

Suggestions:

1. Add a new GetResults method to ResultsRetriver which does not take any parameters. Rewire all code around the interface to call the correct version based on validity of pagingInfo.
2. Ignore the pagingInfo parameter.
3. Ignore the pagingInfo parameter but throw a PagingNotSupportedException() if a valid pagingInfo parameter is supplied to alert the caller to the fact that the parameter will be ignored and they may need to work around this.
4. Argue that what the programmer is writing is not really a ResultsRetriver as a ResultsRetriver must support paging by its original definition. So a new interface must be defined NonPagedResultsRetriver with a GetResults() method taking no parameters. The refactor to include this interface with surrounding code that currently works with ResultsRetriver to also work with NonPagedResultsRetriver
5. Something else?

Question

What is the optimal solution and why?

See Also

Minimal design vs anticipated use

Answer 1

In general, the best solution would be to make the new results retriever conform to the contract of the interface by doing paging in code. Ignoring the paging info is a violation of the Liskov Substitution Principle, and will lead to bugs. If that is prohibitively expensive, take that as a hint that this new retriever maybe isn't a good idea.

Adding a plain old GetResults() is maybe fine, but given it isn't there already makes me think that it isn't there to dissuade its misuse. Combine that with having to go back in and modify a bunch of existing implementations makes me think that you're not gaining much by doing that, so would probably not do that.