Java 为什么Stream.Builder同时具有add和accept方法？

我使用的是一个，我偶然发现这个接口有两种方法，即

accept（T）

和

add（T）

。唯一的区别是前者返回

void

，后者返回

Stream.Builder

文档中甚至提到了这些方法，使其具有相同的默认实现：

默认实现的行为方式如下所示：

accept(t)
return this;

请注意，他们忘记了分号，但这是另一个故事

我的问题是：为什么他们有两种方法向流生成器添加内容？我认为这会使API变得混乱，我认为他们想这样做

有什么令人信服的理由这样做吗？

我猜：

扩展

消费者

，因此它必须实现

accept（T）

方法

---

但是

accept（T）

返回

void

，所以我认为他们添加了

add（T）

是为了方便：构建器模式实现中的方法通常返回

这个
，以便能够链接建筑并最终调用
build（）
一些静态代码分析工具（我想是某种程度上的IntelliJ，还是Checkstyle？）当您调用返回类型为的方法而未将该返回类型分配给变量时，您会抱怨，
void
one。而返回类型为的方法当然可以用于在单行中链接调用。
accept
源于
消费者
和
add
允许典型的链接调用（流畅风格）@Sweeper我的意思是-Conffusion的答案解释得更好。此外，当将streambuilder视为一个构建器时，“add”是正确的名称（我打赌如果我采访100名开发人员，他们中的99人会说“add”，没有人会说“accept”）。如果您将该构建器视为消费者，那么从完全不同的角度来看，“接受”突然变得明智。我知道，
无效接受
是从
消费者
继承而来的。这对我来说是有意义的。但如果将其用作
消费者
，则只需执行
.callWithConsumer（builder:：add）
，一开始就不需要让它成为
消费者。但是他们选择了这样做，所以他们必须实现它。