java - 在 map 中使用 Optional

Question

好的，在我开始解释我的问题之前，我想让你知道我知道 Optional 背后的设计理念。并且它不打算用于字段或集合，但我目前在 Kotlin 中编写了很多程序并且真的不喜欢使用 null .

所以我有一个基于节点的编辑器，就像在虚幻引擎中一样，每个节点都有 ConnectionBox es，它可以是空闲的，也可以被 Connection 占用.

所以有不同的方式来表达这个，其中一种是使用映射每个 ConnectionBox 的 map 。到 Connection喜欢:

Map<ConnectionBox, Connection> connectionEndPoints;

和Connection可能是 null如果ConnectionBox免费。我不喜欢这样，因为其他开发人员不知道此 Map 的功能并且它可能返回 null对于现有的 ConnectionBox .

所以我很想使用:

Map<ConnectionBox, Optional<Connection>> connectionEndPoints;

它更好地显示了意图，您甚至可以这样阅读:
“这个 ConnectionBox 可能附加了一个 Connection。”

我的问题是:为什么我不应该这样做，即使它更清楚地显示了意图并阻止了 NPE秒。每个 SO 线程和每个博客文章都说这是糟糕的风格，甚至编译器都说我不应该在警告的情况下这样做。

---

根据要求，这里有一个不鼓励使用 Optional 的 SO 线程作为字段或集合值:Uses for Optional

这是警告(事实证明这是来自 IntelliJ 的警告):
警告:可选用作字段 {fieldName} 的类型

---

确定后推荐Connection引用应位于 ConnectioBox 内问题只是转移了。

为什么是:

class ConnectionBox {
    Optional<Connection> connection;
    ...

比

class ConnectionBox {
    Connection connection; //may be null
    ...

除非我发表评论，否则您看不到您可能会遇到 NPE我不喜欢解释可以 self 解释的代码的注释。

Answer 1

编辑

看完 Stuart Marks(在 Oracle 的 JDK 组核心库团队工作)的演讲后 "Optional – The Mother of All Bikesheds"从 Devoxx 2016 开始，你应该跳转到 54:04 :

Why Not Use Optional in Fields?

• More a style issue than a correctness issue
  • usually there's a better way to model absence of a value
  • use of Optional in fields often arises from slavish desire to eliminate nullable fields
  • remember, eliminating nulls isn't a goal of Optional
• Using Optional in fields...
  • creates another object for every field
  • introduces a dependent load from memory on every field read
  • clutters up your code
  • to what benefit? ability to chain methods?

原帖

根据 IntelliJ 的检查器(Preferences > Editor > Inspections > 'Optional' used as field or parameter type):

Optional was designed to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result". Using a field with type java.util.Optional is also problematic if the class needs to be Serializable, which java.util.Optional is not.

这也适用于集合，以防您必须 serialize他们。此外，请查看这些链接:

• Java 8 Optional: What's the Point?

  So to recap - in an attempt to get rid of NullPointerExceptions we have a new class that:
  
  

  • Throws NullPointerExceptions
  • Can itself be null, causing a NullPointerException
  • Increases heap size
  • Makes debugging more difficult
  • Makes serializing objects, say as an XML or JSON for an external client, much more difficult

• Why java.util.Optional is broken

  The final irony is that by attempting to discourage nulls, the authors of this class have actually encouraged its use. I'm sure there are a few who will be tempted to simply return null from their functions in order to "avoid creating an unnecessary and expensive Optional reference", rather than using the correct types and combinators.

如果您关心可读性，您还可以使用 @Nullable(在 Eclipse 和 IntelliJ 中可用):

class ConnectionBox {
    @Nullable
    Connection connection;
    // ...
}

或者，您可以创建一个可选的 getter:

class ConnectionBox {
    Connection connection;
    // ...
    Optional<Connection> getConnection() {
        return Optional.ofNullable(connection);
    }
}