使用peek（）修改流元素是否是反模式？

假设我有一个事物流，并且想在流中“丰富”它们，我可以使用peek()它，例如：

streamOfThings.peek(this::thingMutator).forEach(this::someConsumer);

假设在代码的这一点上对事物进行变异是正确的行为-例如，该thingMutator方法可以将“ lastProcessed”字段设置为当前时间。

但是，peek()在大多数情况下，它的意思是“看起来，但不要碰”。

是使用peek()到发生变异流元素的反模式或不明智的？

编辑：

另一种更常规的方法是转换消费者：

private void thingMutator(Thing thing) {
    thing.setLastProcessed(System.currentTimeMillis());
}

到返回参数的函数：

private Thing thingMutator(Thing thing) {
    thing.setLastProcessed(currentTimeMillis());
    return thing;
}

并map()改用：

stream.map(this::thingMutator)...

但这会引入敷衍的代码（return），但我不认为它会更清晰，因为您知道peek()返回的对象相同，但是map()乍一看并不清楚它是同一类对象。

此外，使用peek()lambda可以突变，但是map()您必须构建火车残骸。比较：

stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...)
stream.map(t -> {t.setLastProcessed(currentTimeMillis()); return t;}).forEach(...)

我认为peek()版本更清晰，lambda也很明显是变异的，因此没有“神秘的”副作用。同样，如果使用方法引用，并且该方法的名称明确暗含了突变，则该名称也很明显。

就个人而言，我不会回避使用peek()变异-我觉得这很方便。

没错，英语中的“窥视”一词的意思是“看，但不要碰”。

但是，JavaDoc指出：

窥视

流窥视（消费者行为）

返回由该流的元素组成的流，并在从结果流中消耗元素时对每个元素另外执行提供的操作。

关键词：“执行……行动”和“消耗”。JavaDoc非常清楚，我们应该期望peek能够修改流。

但是，JavaDoc还声明：

API注意：

存在此方法主要是为了支持调试，您需要在其中查看流过管道中特定点的元素

这表明它更多地用于观察，例如记录流中的元素。

我从所有这些中得到的是，我们可以使用流中的元素执行操作，但应避免使流中的元素发生变异。例如，继续在对象上调用方法，但尝试避免使对象上的操作发生变异。

至少，我会按照以下方式在您的代码中添加简短的注释：

// Note: this peek() call will modify the Things in the stream.
streamOfThings.peek(this::thingMutator).forEach(this::someConsumer);

对于此类评论的有用性存在不同意见，但在这种情况下，我将使用此类评论。

它很容易被误解，所以我会避免像这样使用它。最好的选择可能是使用lambda函数将所需的两个动作合并到forEach调用中。您可能还需要考虑返回一个新对象，而不是对现有对象进行突变-它的效率可能会略低，但它可能会导致代码更具可读性，并减少了意外地将修改后的列表用于应执行的另一操作的可能性已收到原件。

API说明告诉我们，此方法主要是为调试/记录/触发统计信息等操作添加的。

@apiNote存在此方法主要是为了支持调试，您需要在其中*看到流过管道中特定点的元素：*

       {@码
     * Stream.of（“一个”，“两个”，“三个”，“四个”）
     * .filter（e-> e.length（）> 3）
     * .peek（e-> System.out.println（“过滤值：” + e））
     * .map（String :: toUpperCase）
     * .peek（e-> System.out.println（“ Mapped value：” + e））
     * .collect（Collectors.toList（））;
     *}