Em fluxos Java, é realmente espiada apenas para depuração?

Estou lendo sobre fluxos Java e descobrindo coisas novas à medida que avança. Uma das coisas novas que encontrei foi a peek()função. Quase tudo o que li na espiada diz que deve ser usado para depurar seus Streams.

E se eu tivesse um Stream em que cada Conta tivesse um nome de usuário, um campo de senha e um método de login () e logIn ().

eu também tenho

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

e

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

Por que isso seria tão ruim?

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

Agora, até onde sei, isso faz exatamente o que se pretende fazer. Isto;

• Leva uma lista de contas
• Tenta fazer login em cada conta
• Filtra qualquer conta que não esteja logada
• Coleta as contas conectadas em uma nova lista

Qual é a desvantagem de fazer algo assim? Algum motivo para eu não prosseguir? Por fim, se não esta solução, então o que?

A versão original disso usava o método .filter () da seguinte maneira;

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

A principal conclusão disso:

Não use a API de maneira não intencional, mesmo que ela atinja seu objetivo imediato. Essa abordagem pode quebrar no futuro e também não está clara para futuros mantenedores.

Não há mal nenhum em dividir isso em várias operações, pois são operações distintas. Não é mal em usar a API de forma pouco clara e não intencional, o que pode ter ramificações se este comportamento particular é modificado em futuras versões do Java.

O uso forEachdessa operação deixaria claro para o mantenedor que existe um efeito colateral pretendido em cada elemento de accountse que você está executando alguma operação que pode modificá-lo.

Também é mais convencional no sentido de que peeké uma operação intermediária que não opera em toda a coleção até que a operação do terminal seja executada, mas forEaché de fato uma operação do terminal. Dessa forma, você pode argumentar fortemente sobre o comportamento e o fluxo do seu código, em vez de fazer perguntas sobre se peeko mesmo se comportaria forEachnesse contexto.

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

O importante que você precisa entender é que os fluxos são acionados pela operação do terminal . A operação do terminal determina se todos os elementos devem ser processados ​​ou algum. O mesmo collectacontece com uma operação que processa cada item, enquanto findAnypode parar de processar itens depois de encontrar um elemento correspondente.

E count()pode não processar nenhum elemento quando pode determinar o tamanho do fluxo sem processar os itens. Como essa é uma otimização não feita no Java 8, mas que será no Java 9, pode haver surpresas quando você alterna para o Java 9 e possui um código que depende do count()processamento de todos os itens. Isso também está conectado a outros detalhes dependentes da implementação, por exemplo, mesmo no Java 9, a implementação de referência não poderá prever o tamanho de uma fonte de fluxo infinita combinada, limitembora não exista uma limitação fundamental que impeça essa previsão.

Como peekpermite “executar a ação fornecida em cada elemento à medida que os elementos são consumidos no fluxo resultante ”, ele não exige o processamento de elementos, mas executará a ação dependendo do que a operação do terminal precisar. Isso implica que você deve usá-lo com muito cuidado se precisar de um processamento específico, por exemplo, deseja aplicar uma ação em todos os elementos. Funciona se é garantido que a operação do terminal processa todos os itens, mas mesmo assim, você deve ter certeza de que nem o próximo desenvolvedor alterará a operação do terminal (ou você esquecerá esse aspecto sutil).

Além disso, enquanto os fluxos garantem manter a ordem de encontro para uma certa combinação de operações, mesmo para fluxos paralelos, essas garantias não se aplicam peek. Ao coletar em uma lista, a lista resultante terá a ordem correta para fluxos paralelos ordenados, mas a peekação pode ser invocada em uma ordem arbitrária e simultaneamente.

Portanto, a coisa mais útil com a qual você pode fazer peeké descobrir se um elemento de fluxo foi processado, exatamente o que a documentação da API diz:

Esse método existe principalmente para oferecer suporte à depuração, onde você deseja ver os elementos à medida que eles fluem após um certo ponto em um pipeline

Talvez uma regra prática seja que, se você usar a espiada fora do cenário "debug", deverá fazê-lo apenas se tiver certeza de quais são as condições de filtragem intermediária e final. Por exemplo:

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

parece ser um caso válido em que você deseja, em uma operação, transformar todos os Foos em barras e dizer a todos.

Parece mais eficiente e elegante do que algo como:

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

e você não itera duas vezes uma coleção.

Eu diria que peekfornece a capacidade de descentralizar código que pode alterar objetos de fluxo ou modificar o estado global (com base neles), em vez de colocar tudo em uma função simples ou composta passada para um método terminal.

Agora, a pergunta pode ser: devemos alterar objetos de fluxo ou alterar o estado global de dentro das funções na programação java de estilo funcional ?

Se a resposta a qualquer um dos acima de 2 perguntas é sim (ou: em alguns casos, sim), então peek()é definitivamente não só para fins de depuração , pela mesma razão que forEach()não é apenas para fins de depuração .

Para mim, ao escolher entre forEach()e peek(), é o seguinte: Desejo que partes do código que modificam objetos de fluxo sejam anexadas a um composable ou que elas sejam anexadas diretamente ao fluxo?

Eu acho que peek()será melhor emparelhar com métodos java9. por exemplo, takeWhile()pode ser necessário decidir quando parar a iteração com base em um objeto já mutado, portanto, compará-lo forEach()não teria o mesmo efeito.

PS: Eu não mencionei em map()nenhum lugar porque, no caso de querermos modificar objetos (ou estado global), em vez de gerar novos objetos, ele funciona exatamente como peek().

Embora eu concorde com a maioria das respostas acima, tenho um caso em que o uso de espiar parece realmente o caminho mais limpo a seguir.

Semelhante ao seu caso de uso, suponha que você queira filtrar apenas em contas ativas e, em seguida, efetue um logon nessas contas.

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

A espiada é útil para evitar a chamada redundante sem precisar repetir a coleção duas vezes:

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

A solução funcional é tornar o objeto de conta imutável. Portanto, account.login () deve retornar um novo objeto de conta. Isso significa que a operação do mapa pode ser usada para login, em vez de espiar.