Si tratta di valutare i vantaggi per te stesso , l'autore della libreria e i vantaggi per altri , i programmatori dell'applicazione.
Pubblicare un tipo generale ti lascia libero di cambiare idea in seguito senza violare il contratto, ma allo stesso tempo svaluta il contratto stesso . Se si restituisce una raccolta generica, l'utente non può fare nulla con esso, tranne enumerarlo. Se è tutto ciò che è necessario, bene. Ma se l'utente ha effettivamente bisogno di un ordine ben definito degli elementi restituiti, un Collection non è sufficiente. In un mondo perfetto, ogni programmatore applicativo lo riconoscerebbe e si asterrebbe dal dipendere dall'ordine in cui gli elementi vengono restituiti. Tuttavia (sai dove sta andando ...), nel mondo reale, ciò che probabilmente accadrà è che dichiari i tuoi risultati come Collection , ma li implementa tramite una specie di List , e i tuoi utenti osservano un ordine prevedibile di elementi e arrivare a dipendere da esso. Quindi quando cambi l'implementazione, i loro programmi si interrompono e ti maledicono. Se ti sei impegnato a generare un List in primo luogo, questo non può accadere.
Ecco perché è una buona idea impegnarsi almeno a qualche livello di struttura dati specifica nelle interfacce pubbliche. In realtà è abbastanza raro che tu cambi idea se una struttura dati consentirà duplicati o se consentirà null , o se debba essere ordinato o meno, quindi decisioni come scegliere List su Set aren È così difficile da realizzare e danno ai tuoi utenti più garanzie su cui lavorare (piuttosto che assumere falsamente le cose che sono vere adesso ma potrebbero cambiare senza preavviso).