java - 在 Scala 的案例类和类字段中使用 Optional 是否有代码味道？

Question

关于在 Java 中使用 Optional 的正确方法，在 Stackoverflow 上已经有很多讨论(像 this one、or this 这样的讨论)

到目前为止，在 Java 中对类成员使用 Optional 被广泛认为是一种代码味道，甚至因为它故意不实现 Serializable 接口(interface)而受到劝阻。此外，我们应该避免在 DTO、构造函数和方法的输入参数中使用它。从 OOP 的角度来看，到目前为止我所读到的关于Optional 的所有内容都符合我的理由。

我的问题是，Scala 的 FP 端是否以我们应该使用 Optional 的方式改变了什么？特别是因为在 Scala 中Optional 的实现似乎更加丰富。我找到了很多描述如何在 Scala 中使用它的文章，但没有一篇详尽介绍何时我应该使用它以及何时我不应该。

Answer 1

简答

Option 字段有用例；他们本质上并不坏。然而，即使几个完善的库(例如 ScalaTest )定义了带有 Option 字段的类，后者，IMO，往往是一种代码味道，因为它们经常试图为自己做太多事情好。

在许多情况下，包含可选字段的类型可以轻松且有利地替换为代数数据类型。

一个例子

域名

考虑一个处理账户的业务领域。一个帐户的生命开始时是开放帐户，但最终可能会关闭。在适用的情况下，帐户以及其他数据包含它们的开立和关闭日期。

使用选项字段

下面是一个帐户的实现，使用了一个Option字段:

final case class Account(openedOn: LocalDate, closedOn: Option[LocalDate], ...)

我们还有一个帐户服务，它定义了一个 close 方法:

trait AccountService {
  // ...
  def close(account: Account): Account
}

由于多种原因，这种方法存在问题。一个问题是 Account 的性能不是特别好:因为 closedOn 是一种“盒装”类型，可以这么说，您的间接级别太多了。此外，Account 的内存占用并不理想:“关闭的帐户”包含一个非常无趣的值(None)，这是一种空间浪费。

另一个更严重的问题是 close 方法无法在类型级别强制参数为“开立账户”，结果为“关闭账户”。您必须编写测试来检查您的实现是否执行了此业务规则。

使用小型 ADT(并避开 Option 字段)

考虑以下替代设计:

sealed trait Account { ... }

final case class OpenAccount(openedOn: LocalDate, ...) extends Account

final case class ClosedAccount(openedOn: LocalDate, closedOn: LocalDate, ...) extends Account

这个小的 ADT 解决了性能问题，但还有更多...您现在可以在类型级别对业务规则进行编码!这是一个使非法状态不可表示的例子(归因于 Yaron Minsky 的短语)。因此，您的服务的 API 变得更具表现力并且 harder to misuse :

trait AccountService {
  // ...
  def close(account: OpenAccount): ClosedAccount
}

这个例子可能足以让您相信第二种方法更可取，并且最好避免使用 Option 字段(或者至少谨慎使用)。

资源

有关消除可选字段以使非法状态无法表示的更多信息，请参阅

• Yaron Minsky's blogpost
• Scott Wlaschin's blogpost
• Richard Feldman's elm-conf 2016 talk (跳到 21'25'' 标记，然后倒带并观看整个演讲!)