使用 Stream.ofNullable 处理可空列表是不好的做法吗

Question

this using optionals correctly 中的第 12 项不是可选文章状态有时，我们倾向于&ldquo;过度使用&rdquo;东西。这意味着我们有一个东西，比如 Optional，我们到处都能看到它的用例。在 Optional 的情况下，一个常见的场景涉及链接其方法以获得值的单一目的。避免这种做法并依赖简单明了的代码。也是一样吗Stream.ofNullable？我应该避免这种情况吗：Stream.ofNullable(getHandlers(...))   .flatMap(Collections::stream)   .forEach(handler -> handler.handle(event));赞成这个？List<Handler> handlers = getHandlers(...) if (handlers == null) {    return; // do nothing}handlers.forEach(handler -> handler.handle(event));

Answer 1

我认为“依靠简单明了的代码”的建议在任何地方都是很好的建议，不限于 eitherOptional或Stream.ofNullable.

就题中的具体选择而言：我觉得很难说一个客观上比另一个更简单直白。Stream.ofNullable更简洁，但需要您知道它的作用；显式检查更冗长，但如果您不熟悉s，if可能更容易理解。Stream

当向 API 引入新方法时，可以说它在某种意义上“更难”，因为不熟悉 API 方法的人会发现它更难阅读，因为他们不知道该方法的作用。当然，人们可以反驳说他们应该知道，或者应该预料到会遇到他们不知道的事情。

所以，我基本上是说你应该使用你/你的代码的读者会觉得最舒服的那个。

---

但是，我认为这里不好的做法是getHandlers(...)首先返回 null 。Effective Java中有一项（第 3 版第 54 项，第 2 版第 43 项）关于总是返回一个空列表而不是 null。

此建议在这里非常有效，因为您处理空列表的方式与处理空列表的方式相同。

这样做可以让你写：

List<Handler> handlers = getHandlers(...);
handlers.stream().forEach(...);

这是客观上更简单的代码。

我认为使用它会更好：

for (Handler h : getHandlers(...)) {
  // ...
  }

因为您可以更灵活地在循环内做更多事情（例如中断），而无需使用流（/类似流的方法）。