Qualche tempo fa ho letto una sorta di "regola generale" sulla concretezza dei tipi di parametri del metodo, dei tipi restituiti e dei tipi di proprietà, ma non me lo ricordo.
Ha detto qualcosa su come mantenere i tipi di ritorno il più concreti possibile e il tipo di parametro più astratto possibile ... o viceversa.
Non so se è stato effettivamente un consiglio buono o cattivo, quindi se hai i tuoi pensieri su di esso, ti preghiamo di lasciare un commento.
Saluti.
Avere input 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 del tuo metodo, limitando il modo in cui potrebbero funzionare le sue future implementazioni. Quindi è un compromesso tra diversi obiettivi.
Potresti aver sentito un'estrapolazione della legge di Postel : "Sii prudente in ciò che mandi, liberale in ciò che accettare ".
Principalmente si tratta di massimizzare la riusabilità del codice. È facile trovare casi per dimostrare perché aiuta. Prendi in considerazione la Iterable<T> di Java come esempio. Se l'unica cosa che fa il tuo metodo è iterare attraverso tutti i T s, avendo un Iterable<T> come tipo di parametro ti permette di usare quel metodo con oltre 60 classi built-in, per non parlare delle classi personalizzate che implementano l'interfaccia . Se lo hai limitato, ad esempio, a Vector<T> , qualsiasi codice che chiama il tuo metodo dovrebbe prima convertire in Vector<T> .
D'altro canto, restituire un Iterable<T> da un metodo limita la quantità di codice che può utilizzare il valore restituito a quelli che accettano un parametro Iterable<T> . Se restituisci 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.
Leggi altre domande sui tag object-oriented programming-practices interfaces abstraction