我正在阅读有关 Java 流的信息并在进行过程中发现新事物。我发现的新事物之一是peek()函数。我在 peek 上读到的几乎所有内容都表明它应该用于调试您的 Streams。
peek()
如果我有一个 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(); })
从中得出的关键结论:
不要以非预期的方式使用 API,即使它实现了您的直接目标。 这种方法将来可能会失效,未来的维护者也不清楚。
将其分解为多个操作并没有什么坏处,因为它们是不同的操作。以不明确和无意的方式使用 API 是 有害的,如果在未来的 Java 版本中修改此特定行为,可能会产生影响。
使用forEach这个操作可以让维护者清楚地知道每个元素都有 预期 的副作用accounts,并且你正在执行一些可以改变它的操作。
forEach
accounts
从某种意义上说,它也是更传统的peek一种中间操作,它在终端操作运行之前不对整个集合进行操作,但forEach确实是终端操作。这样,您可以围绕代码的行为和流程提出强有力的论据,而不是询问有关是否会与此上下文中peek的行为相同的问题。forEach
peek
accounts.forEach(a -> a.login()); List<Account> loggedInAccounts = accounts.stream() .filter(Account::loggedIn) .collect(Collectors.toList());