Tuple o Oggetti

Penso che usare Tuples nei limiti dell'API sia problematico. Se ne hai uno solo, è abbastanza facile ricordare che cos'è Item1 , ma quando ne hai 20, diventa più difficile da ricordare.

La domanda è vale la pena di avere nomi per i miei parametri?

Rendere piccole classi è alquanto fastidioso, ma è un piccolo prezzo da pagare per ottenere la possibilità di nominare gli oggetti. Ora, il tuo ide può ricordarti quale è cosa. Il costo di mantenimento della classe è minimo, il costo per definirlo è basso, ma il costo mentale è ricordare cosa diventa 0.

Secondo me, nessuno dei due è corretto. Una soluzione migliore sarebbe avere una classe PojoRetriever che implementa Paginator, che gestisce l'impaginazione e tiene traccia dello stato (cioè la dimensione della pagina, la pagina corrente) in modo che il codice client possa semplicemente chiamare un metodo per determinare se ci sono più dati.

Molto spesso quando senti la necessità di restituire più valori, potresti (dovresti, imo) usare un oggetto per archiviarli / gestirli.

La tua richiesta di informazioni dovrà restituire sia il conteggio degli articoli corrispondenti sia il carico utile attuale di informazioni. In genere, ciò che faccio per questo scenario è creare un oggetto generico che gestisca la logica di impaginazione:

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;}
}

Data la dimensione e la pagina della pagina corrente e il numero totale di record che si applicano alla query, è possibile calcolare tutto il resto. La classe contenitore Page<T> ha gestito tutta la logica di impaginazione e potrebbe essere riutilizzata per qualsiasi tipo di cui avessimo bisogno.

Se le uniche due opzioni che hai sono quelle che hai elencato, allora sono d'accordo con @whatsisname e suggerisco di andare con la classe.

Tuttavia, in questo caso, credo che potresti avere una soluzione migliore:

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

Si riprogetta il metodo getPojos per restituire l'elenco di pojos come parametro out, e il valore di ritorno del metodo è il numero di Pojos rimanenti in qualunque repository da cui li si preleva. Naturalmente, ci sono variazioni a questa soluzione:

• Puoi restituire un bool se sai solo se il repository è vuoto o no, ma non sai quanti pojos ci sono rimasti
• Il parametro List retrievedPojos non deve essere un parametro out, nel qual caso dovresti istanziare e inizializzare l'elenco prima che venga chiamato il metodo - Non lo suggerirei per più motivi

Generalmente, ogni volta che si ha un metodo che restituisce più di un valore, lo si può refactificare per utilizzare due metodi o restituire i valori utilizzando i parametri out.

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

è una versione glorificata di

Pair<List<Pojo>, Boolean>

Finché il tuo team accetta un approccio e si attiene a questo, non lo considero un problema da discutere troppo.

Tuttavia, consiglierei una strategia che non ne faccia uso.

Aggiungi un'altra funzione

Boolean hasMorePages(int page, int pageSize);

Quindi usa quella chiamata di funzione invece di utilizzare la variabile membro hasMore di PojoResponse .

Avvertenza Se hasMorePages è intensivo di calcolo, questa potrebbe non essere l'opzione migliore.