3

如果我正在编写库，我会习惯性地这样编写 Option：

abstract class Option[+A] {
  def map[B](f: A => B): Option[B]
}

case object None extends Option[Nothing] {
  override def map[B](f: Nothing => B): Option[B] = None
}

case class Some[+A](a: A) extends Option[A] {
  override def map[B](f: A => B): Option[B] = new Some(f(a))
}

注意使用多态来map实现。然而，map 的真正实现完全在 Option 类中，它看起来像这样：

def map[B](f: A => B): Option[B] =
    if (isEmpty) None else Some(f(this.get))

我声称我的实现更干净（请参阅其他地方的多态性的优点）并且可能更快。使用类型匹配而Either不是if类似情况，这让我想起了switchC 人在接触 Java 时使用的语句。有趣的是，类似的实现Try遵循我的 OOP 学校。所以我猜在Option. 还有其他原因吗？

4

1 回答 1

3

  1. Option是sealed抽象类，因此它不是 OOP 风格的多态性的目标，因为您不允许使用您的类扩展它。

  2. 大多数方法实现都基于方法get和isEmpty，这些只是在Option保留源之外定义的两个，None而且Some非常小。因此，如果您想了解如何实施flatMap或collect实施，则无需从源的一部分切换到另一部分。我认为，这使该来源更具可读性。

  3. 这些小函数是 JIT 内联的不错选择。需要分派的方法只能通过不安全的优化进行内联，当然这很少发生在Option真正需要的上下文中。所以我怀疑你的实施真的更快。

  4. Functional链接中的vs风格有很多说法OOP，由@mz 和周围的互联网提供。所以我会远离那场特别的圣战。

于 2015-04-26T19:14:16.747 回答