在 Java 流中，peek 真的只用于调试吗？

小编典典

在 Java 流中，peek 真的只用于调试吗？

all

我正在阅读有关 Java 流的信息并在进行过程中发现新事物。我发现的新事物之一是peek()函数。我在 peek
上读到的几乎所有内容都表明它应该用于调试您的 Streams。

如果我有一个 Stream，其中每个 Account 都有一个用户名、密码字段和一个 login() 和 loggedIn() 方法。

我也有

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

和

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

为什么会如此糟糕？

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

现在据我所知，这完全符合它的意图。它;

获取帐户列表
尝试登录每个帐户
过滤掉任何未登录的帐户
将登录的帐户收集到一个新列表中

做这样的事情有什么缺点？有什么理由我不应该继续？最后，如果不是这个解决方案，那又是什么？

原始版本使用 .filter() 方法如下；

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

阅读 77

2022-07-18

共1个答案

小编典典

从中得出的关键结论：

不要以非预期的方式使用 API，即使它实现了您的直接目标。 这种方法将来可能会失效，未来的维护者也不清楚。

将其分解为多个操作并没有什么坏处，因为它们是不同的操作。以不明确和无意的方式使用 API 是有害的，如果在未来的 Java
版本中修改此特定行为，可能会产生影响。

使用forEach这个操作可以让维护者清楚地知道每个元素都有预期的副作用accounts，并且你正在执行一些可以改变它的操作。

从某种意义上说，它也是更传统的peek一种中间操作，它在终端操作运行之前不对整个集合进行操作，但forEach确实是终端操作。这样，您可以围绕代码的行为和流程提出强有力的论据，而不是询问有关是否会与此上下文中peek的行为相同的问题。forEach

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

2022-07-18