Qualche tempo fa ho letto una sorta di "regola empirica" sulla concretezza dei tipi di parametri del metodo, dei tipi restituiti e dei tipi di proprietà, ma non me lo ricordo.
Diceva qualcosa su come mantenere i tipi di ritorno il più concreti possibile e i tipi di parametri il più astratti possibile ... o viceversa.
Non so se fosse in realtà un consiglio buono o cattivo, quindi se hai i tuoi pensieri al riguardo, per favore lascia un commento.
Saluti.
Risposte:
Non serve più, non promettere di meno.
La frase deriva dalle idee "Design by Contract", introdotte da Bertrand Meyer.
http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract
Vedi anche il "principio di sostituzione di Liskov"
/programming/56860/what-is-the-liskov-substitution-principle
Avere input astratti e output concreti rende la tua funzione più generale. Ciò significa che può essere utilizzato in più modi. D'altra parte, pone vincoli più forti al tuo metodo, limitando il modo in cui le future implementazioni potrebbero funzionare. Quindi è un compromesso tra obiettivi diversi.
Potresti aver sentito un'estrapolazione della legge di Postel : "Sii conservatore in ciò che invii, liberale in ciò che accetti".
Principalmente si tratta di massimizzare la riusabilità del codice. È facile trovare casi per dimostrare perché aiuta. Considera Java Iterable<T>come esempio. Se l'unica cosa che fa il tuo metodo è scorrere tutte le Ts, avere un Iterable<T>come tipo di parametro ti consente di utilizzare quel metodo con oltre 60 classi integrate, per non parlare delle classi personalizzate che implementano l'interfaccia. Se lo hai limitato a, diciamo, Vector<T>allora qualsiasi codice che chiama il tuo metodo dovrebbe convertirsi in un Vector<T>primo.
D'altra parte, il ritorno di un Iterable<T>da un metodo limita la quantità di codice che può utilizzare il valore di ritorno di quelli che prendono un Iterable<T>parametro. Se si restituisce un tipo molto concreto, come Vector<T>, allora il tuo valore di ritorno può essere passato in qualsiasi metodo che prende un Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, o AbstractCollection<T>, e funzionerà come previsto.