我正在阅读有关Java流的资料,并在阅读过程中发现新的东西。我发现的一个新东西是peek()函数。几乎所有我读到的peek说它应该用来调试你的流。

如果我有一个流,其中每个帐户都有一个用户名,密码字段和login()和loggedIn()方法。

我还有

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

and

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();
    })

当前回答

很多答案都有很好的观点,尤其是Makoto(被接受的)的答案相当详细地描述了可能存在的问题。但没有人真正说明它是如何出错的:

[1]-> IntStream.range(1, 10).peek(System.out::println).count();
|  $6 ==> 9

没有输出。

[2]-> IntStream.range(1, 10).filter(i -> i%2==0).peek(System.out::println).count();
|  $9 ==> 4

输出数字2,4,6,8。

[3]-> IntStream.range(1, 10).filter(i -> i > 0).peek(System.out::println).count();
|  $12 ==> 9

输出数字1 ~ 9。

[4]-> IntStream.range(1, 10).map(i -> i * 2).peek(System.out::println).count();
|  $16 ==> 9

没有输出。

[5]-> Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9).peek(System.out::println).count();
|  $23 ==> 9

没有输出。

[6]-> Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9).stream().peek(System.out::println).count();
|  $25 ==> 9

没有输出。

[7]-> IntStream.range(1, 10).filter(i -> true).peek(System.out::println).count();
|  $30 ==> 9

输出数字1 ~ 9。

[1]-> List<Integer> list = new ArrayList<>();
|  list ==> []
[2]-> Stream.of(1, 5, 2, 7, 3, 9, 8, 4, 6).sorted().peek(list::add).count();
|  $7 ==> 9
[3]-> list
|  list ==> []

(你懂的。)

这些示例是在jshell (Java 15.0.2)中运行的,并模拟了转换数据的用例(取代System。Out::println by list::add例如,在一些回答中也做过),并返回添加了多少数据。目前观察到的情况是,任何可以过滤元素的操作(如过滤或跳过)似乎都强制处理所有剩余的元素,但不需要保持这种方式。

其他回答

功能性的解决方案是使帐户对象不可变。因此account.login()必须返回一个新的account对象。这意味着映射操作可以用于登录,而不是查看。

我想说的是,peek提供了去中心化代码的能力,这些代码可以改变流对象,或修改全局状态(基于它们),而不是将所有东西都塞进一个简单的或组合的函数中,传递给终端方法。

现在的问题可能是:在函数式java编程中,我们应该改变流对象还是从函数内部改变全局状态?

如果以上两个问题中的任何一个的答案是肯定的(或者:在某些情况下是),那么peek()肯定不仅仅是用于调试的目的,就像forEach()不仅仅是用于调试的目的一样。

对于我来说,当在forEach()和peek()之间进行选择时,是选择以下内容:我想要突变流对象(或改变全局状态)的代码片段附加到可组合的,还是我想要它们直接附加到流?

我认为peek()将更好地与java9方法配对。例如,takeWhile()可能需要根据一个已经发生变化的对象决定何时停止迭代,因此与forEach()匹配将不会产生相同的效果。

注:我没有在任何地方提到map(),因为如果我们想要突变对象(或全局状态),而不是生成新对象,它的工作方式与peek()完全相同。

尽管.peek的文档说明说“方法的存在主要是为了支持调试”,但我认为它具有普遍的相关性。首先,文档说“主要”,所以为其他用例留下了空间。多年来它没有被弃用,在我看来,关于它被移除的猜测是徒劳的。

我想说,在一个我们仍然需要处理副作用方法的世界里,它有一个有效的位置和效用。流中有许多使用副作用的有效操作。许多已经在其他答案中提到,我只是在这里添加一个对象集合上设置一个标志,或者将它们注册到注册表中,然后在流中进一步处理对象。更不用说在流处理期间创建日志消息了。

我支持在不同的流操作中有不同的动作的想法,因此我避免将所有内容都推入最终的. foreach。我更喜欢.peek而不是等效的带有lambda的.map,除了调用副作用方法之外,它的唯一目的是返回传入的in参数。.peek告诉我,一旦遇到这个操作,输入的内容也会输出,而且我不需要读取lambda来找出。从这个意义上说,它是简洁的,富有表现力的,并提高了代码的可读性。

话虽如此,我同意使用.peek时的所有注意事项,例如,注意使用.peek的流的终端操作的影响。

虽然我同意上面的大多数答案,但我有一个案例,使用peek似乎是最干净的方法。

与您的用例类似,假设您希望仅对活动帐户进行过滤,然后在这些帐户上执行登录。

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

Peek有助于避免冗余调用,同时不必迭代集合两次:

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

很多答案都有很好的观点,尤其是Makoto(被接受的)的答案相当详细地描述了可能存在的问题。但没有人真正说明它是如何出错的:

[1]-> IntStream.range(1, 10).peek(System.out::println).count();
|  $6 ==> 9

没有输出。

[2]-> IntStream.range(1, 10).filter(i -> i%2==0).peek(System.out::println).count();
|  $9 ==> 4

输出数字2,4,6,8。

[3]-> IntStream.range(1, 10).filter(i -> i > 0).peek(System.out::println).count();
|  $12 ==> 9

输出数字1 ~ 9。

[4]-> IntStream.range(1, 10).map(i -> i * 2).peek(System.out::println).count();
|  $16 ==> 9

没有输出。

[5]-> Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9).peek(System.out::println).count();
|  $23 ==> 9

没有输出。

[6]-> Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9).stream().peek(System.out::println).count();
|  $25 ==> 9

没有输出。

[7]-> IntStream.range(1, 10).filter(i -> true).peek(System.out::println).count();
|  $30 ==> 9

输出数字1 ~ 9。

[1]-> List<Integer> list = new ArrayList<>();
|  list ==> []
[2]-> Stream.of(1, 5, 2, 7, 3, 9, 8, 4, 6).sorted().peek(list::add).count();
|  $7 ==> 9
[3]-> list
|  list ==> []

(你懂的。)

这些示例是在jshell (Java 15.0.2)中运行的,并模拟了转换数据的用例(取代System。Out::println by list::add例如,在一些回答中也做过),并返回添加了多少数据。目前观察到的情况是,任何可以过滤元素的操作(如过滤或跳过)似乎都强制处理所有剩余的元素,但不需要保持这种方式。