2015-01-27 8 views
6

In Java 8 Sto sostituendo sempre più i valori di ritorno Collection con Stream.Flusso di ritorno anziché elenco

Allora, dove avrei una volta avuto:

public List<Element> getElementList() { 
    return elements; 
} 

ora sto usando:

public Stream<Element> streamElements() { 
    return elements.stream(); 
} 

mie argomentazioni per questo sono:

  1. Si fa rispettare l'immutabilità del sottostante lista
  2. Nasconde il fatto che ci sia un elenco sottostante. Potrebbe essere successivamente modificato in un set o in un'altra struttura senza modificare la firma del metodo.
  3. Incapsula piacevolmente che l'utente del metodo dovrebbe fare qualcosa con gli articoli non con una lista.
  4. Può essere banalmente parallelised in seguito, se necessario.

Infatti ora, nel mio codice, restituendo un List o qualche altra collezione è esplicitamente un riconoscimento del fatto che l'utente può prendere in considerazione la raccolta mutabile e dovrebbe essere in grado di cambiarlo.

Chiaramente alcuni di questi può essere realizzato con collezioni immutabili.

La mia domanda è: qualcuno può vedere qualche svantaggio con questo design? Ci sono vantaggi delle collezioni immutabili oltre la restituzione di un Stream?

+2

risposta qui: http://stackoverflow.com/questions/24676877/should-i-return-a-collection-or-a-stream/24679745#24679745 –

+0

@BrianGoetz Posso avere la tua firma per favore: P –

+1

Vedere anche http://stackoverflow.com/q/27179175/2711488 – Holger

risposta

10

Non sto dicendo che non è necessario restituire un flusso, e tanto meno che non si dovrebbe mai restituire un ruscello, ma farlo ha anche molti svantaggi:

  • non dire all'utente di l'API se la raccolta è ordinata (elenco) o meno (Set), o allineati (SortedSet)
  • che non dice l'utente delle API se la raccolta può contenere duplicati (List) o meno (Set)
  • non permette all'utente di accedere facilmente e rapidamente il primo o l'ultimo elemento della lista, o anche per conoscere quale formato che ha.
  • se l'utente delle API deve fare più passaggi sulla raccolta, è costretto a copiare ogni elemento in una nuova collezione.

Direi che scegliere di restituire un flusso piuttosto che una raccolta dipende anche da ciò che si ha già. Se la raccolta è già materializzata (pensate a un'entità JPA che ha un OneToMany già materializzato come un Set), probabilmente restituirei un wrapper immutabile alla raccolta. Se, d'altra parte, la raccolta da restituire è il risultato di un calcolo o di una trasformazione di un'altra raccolta, restituire un flusso potrebbe essere una scelta migliore.

+0

Questa è una buona risposta e l'ho accettata, ma dopo aver letto l'altra risposta è chiaro che questa è davvero una domanda doppia. Detto questo, preferisco la tua risposta all'altra in modo che ti piaccia ripubblicare lì. – sprinter

+0

+1: la risposta di Brian Goetz è decisamente favorevole al "flusso", ma in realtà, l'unica ragione veramente convincente per andare con il flusso è la pigrizia. Fondamentalmente, Stream è un miglioramento su * Iterator * molto più che su * Collection *. –

1

mi viene in mente diversi casi:

  1. Quando il chiamante vuole davvero "ottenere e mantenere" i valori invece di elaborazione loro solo una volta.
  2. Quando si restituisce ogni volta che un nuovo oggetto non è accettabile per la memoria o il problema di prestazioni, in cui la restituzione di un oggetto statico è preferibile (questo è possibile per calcolo ad alte prestazioni o dove si desidera avere il tempo di elaborazione deterministica nel metodo in modo che si desidera avere GC minimo).

Ma sì, molte elaborazioni possono essere semplificate.

Problemi correlati