在Option.isEmpty和Option.get上使用Option.map有什么好处？

Question

我是来自Java背景的Scala新手，目前对考虑Option[T]的最佳实践感到困惑。

我觉得使用Option.map更实用，更美观，但这并不是说服其他人的好理由。 有时，isEmpty检查感觉更直接，因此更具可读性。 有客观上的优势，还是个人偏好？

例：

变化1：

someOption.map{ value => 
  {
    //some lines of code
  }
} orElse(foo)

变化2：

if(someOption.isEmpty){
  foo
} else{
  val value = someOption.get
  //some lines of code
}

我故意排除使用fold或模式匹配的选项。 我现在对将Option视为一个集合的想法感到高兴，并且使用模式匹配进行简单的isEmpty检查是滥用模式匹配的恕我直言。 但无论我为什么不喜欢这些选项，我都希望将这个问题的范围保持为标题中指定的上述两种变体。

Answer 1

有客观上的优势，还是个人偏好？

我认为客观优势与个人偏好之间存在细微差别。 你不能让人相信任何一个人都有绝对的真理。

使用Scala构造的一元性质所获得的最大优势是组合 。 将操作链接在一起而不必“担心”内部价值的能力是强大的，不仅与Option[T] ，而且还与Future[T] ， Try[T] ， Either[A, B]和返回他们之间（也见Monad变形金刚 ）。

让我们试着看看如何使用Option[T]上的预定义方法来帮助控制流程。 例如，假设您有一个Option[Int] ，只有当它大于一个值时才要相乘，否则返回-1。 在命令式方法中，我们得到：

val option: Option[Int] = generateOptionValue

var res: Int = if (option.isDefined) {
  val value = option.get
  if (value > 40) value * 2 else -1
} else -1

在Option上使用集合样式方法，等价物将如下所示：

val result: Int = option
  .filter(_ > 40)
  .map(_ * 2)
  .getOrElse(-1)

我们现在考虑一个组合案例。 假设我们有一个可能抛出异常的操作。 此外，此操作可能会或可能不会产生价值。 如果它返回一个值，我们想要用该值查询数据库，否则返回一个空字符串。

看一下使用try-catch块的命令式方法：

var result: String = _
try {
  val maybeResult = dangerousMethod()
  if (maybeResult.isDefined) {
    result = queryDatabase(maybeResult.get)
  } else result = ""
}
catch {
  case NonFatal(e) => result = ""
}

现在让我们考虑使用scala.util.Try和Option[String]并将它们组合在一起：

val result: String = Try(dangerousMethod())
  .toOption
  .flatten
  .map(queryDatabase)
  .getOrElse("")

我认为这最终归结为哪一个可以帮助您创建清晰的操作控制流程。 习惯使用Option[T].map而不是Option[T].get将使您的代码更安全 。

总结一下，我不相信有一个单一的事实。 我相信组合可以导致美观，可读，副作用延迟安全代码，我全力以赴。 我认为向他人展示你的感受的最佳方式是给我们看到的例子，并让他们感受到他们可以利用这些工具集的力量。

Answer 2

使用模式匹配进行简单的isEmpty检查是滥用模式匹配的恕我直言

如果你只是想要一个isEmpty检查， isEmpty / isDefined是完全没问题的。 但在你的情况下，你也想获得价值。 使用模式匹配不是滥用; 这正是基本的用例。 使用get允许非常容易地发生错误，例如忘记检查isDefined或进行错误检查：

if(someOption.isEmpty){
  val value = someOption.get
  //some lines of code
} else{
  //some other lines
}

希望测试会抓住它，但没有理由“满怀希望”。

组合器（ map和朋友）比get更好，因为模式匹配是相同的：它们不允许你犯这种错误。 在模式匹配和组合器之间进行选择是一个不同的问题。 一般来说，组合器是首选，因为它们更易于组合（正如Yuval的答案所解释的那样）。 如果你想做一个由单个组合器覆盖的东西，我通常会选择它们; 如果你需要的组合等map ... getOrElse ，或fold多线分支，这取决于具体情况。

Answer 3

在Option情况下，它似乎与你相似，但只考虑Future的情况。 走出Future monad后，你将无法与未来的价值互动。

import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.Promise
import scala.util.{Success, Try}

// create a promise which we will complete after sometime
val promise = Promise[String]();

// Now lets consider the future contained in this promise
val future = promise.future;

val byGet = if (!future.value.isEmpty) {
  val valTry = future.value.get
  valTry match {
    case Success(v) => v + " :: Added"
    case _ => "DEFAULT :: Added"
  }
}  else "DEFAULT :: Added"

val byMap = future.map(s => s + " :: Added")

// promise was completed now
promise.complete(Try("PROMISE"))


//Now lets print both values

println(byGet)
// DEFAULT :: Added

println(byMap)
// Success(PROMISE :: Added)