In Java stream è davvero solo il debugging?

Sto leggendo sui flussi Java e scoprendo nuove cose mentre procedo. Una delle novità che ho scoperto è stata la peek()funzione. Quasi tutto quello che ho letto su Peek dice che dovrebbe essere usato per eseguire il debug dei tuoi stream.

E se avessi un flusso in cui ogni account ha un nome utente, un campo password e un metodo login () e loggIn ().

Ho anche

Consumer<Account> login = account -> account.login();

e

Predicate<Account> loggedIn = account -> account.loggedIn();

Perché questo sarebbe così male?

List<Account> accounts; //assume it's been setup
List<Account> loggedInAccount = 
accounts.stream()
    .peek(login)
    .filter(loggedIn)
    .collect(Collectors.toList());

Ora, per quanto posso dire, fa esattamente quello che è destinato a fare. It;

• Prende un elenco di account
• Cerca di accedere a ciascun account
• Filtra tutti gli account che non hanno effettuato l'accesso
• Raccoglie gli account registrati in un nuovo elenco

Qual è il lato negativo di fare qualcosa del genere? Qualche motivo per cui non dovrei procedere? Infine, se non questa soluzione, allora?

La versione originale di questo utilizzava il metodo .filter () come segue;

.filter(account -> {
        account.login();
        return account.loggedIn();
    })

La chiave da asporto da questo:

Non utilizzare l'API in modo non intenzionale, anche se raggiunge il tuo obiettivo immediato. Tale approccio potrebbe rompersi in futuro ed è anche poco chiaro per i futuri manutentori.

Non vi è alcun danno nel rompere questo a più operazioni, in quanto si tratta di operazioni distinte. L' uso dell'API è dannoso in modo non chiaro e non intenzionale, il che può avere conseguenze se questo comportamento particolare viene modificato nelle future versioni di Java.

L'uso di forEachquesta operazione chiarirebbe al manutentore che esiste un effetto collaterale previsto su ciascun elemento di accountse che si sta eseguendo un'operazione che può mutarlo.

È anche più convenzionale nel senso che peekè un'operazione intermedia che non opera sull'intera raccolta fino a quando l'operazione terminale non viene eseguita, ma forEachè effettivamente un'operazione terminale. In questo modo, puoi fare forti argomentazioni sul comportamento e sul flusso del tuo codice invece di porre domande sul fatto che peeksi comporterebbe come forEachin questo contesto.

accounts.forEach(a -> a.login());
List<Account> loggedInAccounts = accounts.stream()
                                         .filter(Account::loggedIn)
                                         .collect(Collectors.toList());

La cosa importante che devi capire è che i flussi sono guidati dal funzionamento del terminale . L'operazione del terminale determina se tutti gli elementi devono essere elaborati o tutti. Lo stesso collectvale per un'operazione che elabora ciascun elemento, mentre findAnypuò interrompere l'elaborazione degli articoli una volta rilevato un elemento corrispondente.

E count()potrebbe non elaborare alcun elemento quando può determinare la dimensione del flusso senza elaborare gli elementi. Poiché si tratta di un'ottimizzazione non realizzata in Java 8, ma che sarà in Java 9, potrebbero verificarsi sorprese quando si passa a Java 9 e si ha il codice che si basa count()sull'elaborazione di tutti gli elementi. Questo è anche collegato ad altri dettagli dipendenti dall'implementazione, ad esempio anche in Java 9, l'implementazione di riferimento non sarà in grado di prevedere la dimensione di una sorgente di flusso infinita combinata con limitmentre non vi è alcuna limitazione fondamentale che impedisce tale previsione.

Poiché peekconsente di "eseguire l'azione fornita su ciascun elemento quando gli elementi vengono consumati dal flusso risultante ", non impone l'elaborazione degli elementi ma eseguirà l'azione in base alle esigenze dell'operazione del terminale. Ciò implica che devi usarlo con grande cura se hai bisogno di una particolare elaborazione, ad esempio vuoi applicare un'azione su tutti gli elementi. Funziona se l'operazione del terminale è garantita per elaborare tutti gli elementi, ma anche in questo caso, devi essere sicuro che non lo sviluppatore successivo cambi l'operazione del terminale (o dimentichi quell'aspetto sottile).

Inoltre, mentre i flussi garantiscono di mantenere l'ordine di incontro per una determinata combinazione di operazioni anche per i flussi paralleli, queste garanzie non si applicano a peek. Quando si raccoglie in un elenco, l'elenco risultante avrà il giusto ordine per i flussi paralleli ordinati, ma l' peekazione può essere invocata in un ordine arbitrario e contemporaneamente.

Quindi la cosa più utile che puoi fare peekè scoprire se è stato elaborato un elemento stream che è esattamente ciò che dice la documentazione API:

Questo metodo esiste principalmente per supportare il debug, in cui si desidera vedere gli elementi mentre passano oltre un certo punto in una pipeline

Forse una regola empirica dovrebbe essere che se usi la sbirciatina al di fuori dello scenario "debug", dovresti farlo solo se sei sicuro di quali siano le condizioni di filtro intermedio e di terminazione. Per esempio:

return list.stream().map(foo->foo.getBar())
                    .peek(bar->bar.publish("HELLO"))
                    .collect(Collectors.toList());

sembra essere un caso valido dove vuoi, in una sola operazione per trasformare tutti i Foos in Bar e salutarli tutti.

Sembra più efficiente ed elegante di qualcosa di simile:

List<Bar> bars = list.stream().map(foo->foo.getBar()).collect(Collectors.toList());
bars.forEach(bar->bar.publish("HELLO"));
return bars;

e non finisci per ripetere due volte una raccolta.

Direi che peekoffre la possibilità di decentralizzare il codice che può mutare gli oggetti di flusso o modificare lo stato globale (basato su di essi), invece di inserire tutto in una funzione semplice o composta passata a un metodo terminale.

Ora la domanda potrebbe essere: dovremmo mutare gli oggetti stream o cambiare lo stato globale all'interno delle funzioni nella programmazione Java in stile funzionale ?

Se la risposta a una delle 2 domande precedenti è sì (o: in alcuni casi sì), allora non peek()è sicuramente solo a scopo di debug , per lo stesso motivo che forEach()non è solo a scopo di debug .

Per me quando si sceglie tra forEach()e peek(), è scegliere quanto segue: Voglio parti di codice che mutano gli oggetti stream da allegare a un compostabile o voglio che si colleghino direttamente allo stream?

Penso peek()che abbinerà meglio ai metodi java9. ad esempio takeWhile()potrebbe essere necessario decidere quando interrompere l'iterazione in base a un oggetto già mutato, quindi abbinandoloforEach() avrebbe lo stesso effetto.

PS Non ho fatto riferimento da map()nessuna parte perché nel caso in cui vogliamo mutare oggetti (o stato globale), piuttosto che generare nuovi oggetti, funziona esattamente come peek().

Anche se sono d'accordo con la maggior parte delle risposte sopra, ho un caso in cui l'uso della sbirciata in realtà sembra il modo più pulito di procedere.

Simile al tuo caso d'uso, supponi di voler filtrare solo su account attivi e quindi eseguire un accesso su questi account.

accounts.stream()
    .filter(Account::isActive)
    .peek(login)
    .collect(Collectors.toList());

Peek è utile per evitare la chiamata ridondante senza dover ripetere due volte la raccolta:

accounts.stream()
    .filter(Account::isActive)
    .map(account -> {
        account.login();
        return account;
    })
    .collect(Collectors.toList());

La soluzione funzionale è rendere immutabile l'oggetto account. Quindi account.login () deve restituire un nuovo oggetto account. Ciò significa che l'operazione mappa può essere utilizzata per l'accesso anziché per sbirciatina.