Tuples or Objects

Question

Today, talking with some colleagues of mine, we were discussing the usage of tuples. The specific problem was: we have an API returning a list of some kind of objects (let's say POJO instances)

public List<Pojo> getPojos()

we decided to use pagination in order to prevent enormous responses

public List<Pojo> getPojos(int page, int pageSize)

the next step was: can we return both the list and a boolean saying if more results are available preventing useless calls?

My approach was to consider the results as a pair of values

public Pair<List<Pojo>, Boolean> getPojos(int page, int pageSize)

Some colleagues say that this approach can hide the meaning of the returned variables because it is not explicit what the boolean means, their proposal was to introduce an "ad hoc" object to handle the response

class PojoResponse{
    List<Pojo> result;
    Boolean hasMore;
}
public PojoResponse getPojos(int page, int pageSize)

In my opinion, this solution breaks the uniformity of the APIs, introduces new classes that should be maintained and, in my opinion, hides the real objective of the method, in this case, return a list of POJOs.

What is your opinion on that problem? Find articles on these "style problems" on the internet is not always so easy.

Answer 1

I think using Tuples in API boundaries is troublesome. If you just have one, it's easy enough to remember what Item1 is, but when you have 20, it gets harder to remember.

The question is is it worth it having names for my parameters?

Making little classes is somewhat annoying, but it's a small price to pay to gain the ability to name the items. Now, your IDE can remind you which is what. The maintenance cost of the class is minimal, the up front cost of defining it is low, but the mental cost is remembering what's what becomes 0.

Answer 2

In my opinion, neither is correct. A better solution would be to have a PojoRetriever class which implements Paginator, which handles the pagination and keeps track of the state (i.e. page size, current page) so that the client code can simply call a method to determine if there is more data.

A lot of the time when you feel the need to return multiple values, you could (should, imo) use an object to store/handle them.

Answer 3

Your query for information will need to return both count of matching items as well as the current payload of information. Typically what I do for this scenario is to create a generic object that handles the pagination logic:

public class Page<T>
{
    public int Total {get;}
    public int PageSize {get;set;}
    public int PageNum {get;set;}
    public bool HasNext {get;}
    public bool HasPrevious {get;}
    public List<T> Records {get;}
}

Given the current page size and page, and the total number of records that apply to the query, everything else could be calculated. The container class Page<T> handled all the pagination logic, and it could be reused for any type we needed.

Answer 4

If the only two options you have are the ones you listed, then I have to agree with @whatsisname and suggest that you go with the class.

However, in this case, I believe that you might have a better solution:

int numberOfRemainingItems getPojos(int page, int pageSize, out List<Pojo> retrievedPojos)

You redesign your getPojos method to return the list of pojos as an out parameter, and the return value of the method is the number of remaining Pojos in whatever repository you are getting them from. Of course, there are variations to this solution:

• You could return a bool if you just know whether the repository is empty or not, but do not know how many pojos are left there
• The List retrievedPojos parameter does not have to be an out parameter, in which case you would have to instantiate and initialize the list before the method is called - I would not suggest this for multiple reasons

Generally, whenever you have a method that returns more than one value, either refactor it to use two methods, or return the values using out parameters.

Answer 5

class PojoResponse{
    List<Pojo> result;
    Boolean hasMore;
}

is a glorified version of

Pair<List<Pojo>, Boolean>

As long as your team agrees to one approach and sticks with it, I don't see it as an issue to debate too much.

However, I would recommend a strategy that uses neither.

Add another function

Boolean hasMorePages(int page, int pageSize);

Then use that function call instead of using the hasMore member variable of PojoResponse.

Caveat If hasMorePages is compute intensive, this might not be the better option.