È accettabile restituire unmodifiableList o dovrei restituire l'array?

Question

Ho il metodo List<Foo> getFoos() che recupera i dati dal server remoto e li restituisce.

Ovviamente, l'utente non deve modificare il numero di elementi dell'elenco perché otterrà dati non sincronizzati con i dati sul server (e se desidera modificare il numero di elementi ha metodi speciali come addFoo()).

Il primo approccio è stato restituire l'array e modificare la firma del metodo su Foo[] getFoos(). Ma è più comune in Java e più conveniente per l'utente operare con le raccolte, quindi ho cambiato la firma in List<Foo> getFoos(). Questo metodo restituisce sempre

Collections.unmodifiableList (originalList)

Così, quando l'utente tenta di cambiare la lista che otterrà RuntimeException.

Ci sono raccomandazioni riguardo la progettazione di API in casi simili?

Answer 1

Collections.unmodifiableList è perfettamente accettabile e dovrebbe essere più veloce (non è necessario creare un array).

Modifica - In termini di progettazione dell'API, è sufficiente rendere chiaro JavaDoc! Le persone che utilizzano un metodo senza leggere il proprio documento meritano la sorpresa: p

Answer 2

Se si desidera una proprietà personalizzata, personalizzata da un oggetto esistente o Elenca in questo caso, perché non provare ad estenderlo o a contenerlo e rendere i relativi accessor per un'eccezione?

Il motivo è perché si potrebbe desiderare di consentire ad altri oggetti client di modificare l'elenco; dipende da quanto sono vicini al livello dell'applicazione i dati restituiti.

Answer 3

Direi anche che è perfettamente accettabile e molto meglio che restituire un array (il quale suggerimento da some deve essere trattato come un tipo deprecato del tutto). Tuttavia, se vuoi essere più esplicito a proposito dell'API, puoi prendere in considerazione la possibilità di restituire uno ImmutableList da Google Collections.

Answer 4

Non riesco praticamente mai a restituire una lista o un array. Se hai una collezione di qualcosa, quasi sempre ha un codice SOME da qualche parte associato che dovrebbe far parte di quella raccolta. Non avendo una classe attorno alla collezione, ti stai costringendo a duplicare quel codice in luoghi diversi in cui viene utilizzata la raccolta.

C'è anche, in genere, una o due variabili associate alla raccolta. Scoprirai che li passi ogni volta che passi la collezione. Questi appartengono alla classe della business logic che avvolge la collezione.

Answer 5

Se si dispone di completa libertà e sembra che tu lo faccia, allora non dovresti scegliere tra array o Elenco, piuttosto restituire un iteratore. Questo sarebbe utile anche se hai bisogno di unicità, quindi invece di tornare a Set - ancora restituire iteratore.