我正在阅读有关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();
    })

当前回答

关键是:

不要以一种意想不到的方式使用API,即使它实现了您的直接目标。这种方法在将来可能会失效,而且对于未来的维护者来说也不清楚。


将其分解为多个操作并没有害处,因为它们是不同的操作。以一种不明确和意外的方式使用API是有害的,如果在未来的Java版本中修改了这种特定的行为,可能会产生后果。

在此操作中使用forEach将使维护者清楚地知道帐户的每个元素都有预期的副作用,并且您正在执行一些可能会改变它的操作。

它也更传统,因为peek是一个中间操作,在终端操作运行之前不会对整个集合进行操作,但forEach确实是一个终端操作。通过这种方式,您可以围绕代码的行为和流程进行强有力的论证,而不是询问peek在此上下文中的行为是否与forEach相同。

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

其他回答

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

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

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

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

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

为了消除警告,我使用了函数子tee,以Unix的tee命名:

public static <T> Function<T,T> tee(Consumer<T> after) {
    return arg -> {
        f.accept(arg);
        return arg;
    };
}

你可以替换:

  .peek(f)

with

  .map(tee(f))

也许经验法则应该是,如果您确实在“调试”场景之外使用peek,那么只有在确定终止和中间过滤条件是什么时才应该这样做。例如:

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

似乎是一个有效的情况,在一个操作中,将所有的foo转换为bar,并告诉他们都是你好。

似乎比下面的东西更高效和优雅:

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

而且你最终不会迭代一个集合两次。

似乎需要一个helper类:

public static class OneBranchOnly<T> {
    public Function<T, T> apply(Predicate<? super T> test,
                                Consumer<? super T> t) {
        return o -> {
            if (test.test(o)) t.accept(o);
            return o;
        };
    }
}

然后切换偷看与地图:

.map(new OneBranchOnly< Account >().apply(                   
                    account -> account.isTestAccount(),
                    account -> account.setName("Test Account"))
)

结果:只重命名测试帐户的帐户集合(没有维护引用)