0

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

Improve this question
8
  • 1
    Possible duplicate of Interface Design: Specific vs General parameter (A Minimal design vs anticipated use variation) Commented Oct 14, 2015 at 21:05
  • The number one goal of developing a feature is to have it actually achieve the use case. Do these abstractions help achieve that or get in the way of that? Commented Oct 14, 2015 at 21:17
  • Why can't this method apply paging after it has retrieved all results? That might not be the most efficient approach, but it conforms to the interface. Commented Oct 15, 2015 at 7:28
  • @CodesInChaos You mean ANewResultsRetriver::GetResults ? You have to assume that limitation for this question. There may be various reasons, e.g. the results are retrieved through an external service where order cannot be guaranteed and it is not feasible to store them all between paging requests. Commented Oct 15, 2015 at 9:02
  • @Ali: Much of it depends on two factors: 1. How bad is it to ignore the pagingInfo parameter, and 2. would the caller of GetResults be aware of the different results retrievers, or does it just work with a passed-in ResultsRetriver instance? Commented Oct 15, 2015 at 11:19

1 Answer 1

Reset to default
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.

Improve this answer
1
  • 1
    I agree, surely paging info can have values that indicate send all the results on one page, and the calling code should pass that if all the results are required Commented Nov 14, 2015 at 15:32

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.