提取器

提取器

在 Coursera 上，想必你遇到过一个非常强大的语言特性：
模式匹配。
它可以解绑一个给定的数据结构。
这不是 Scala 所特有的，在其他出色的语言中，如 Haskell、Erlang，模式匹配也扮演着重要的角色。

模式匹配可以解构各种数据结构，包括列表、流，以及 样例类 。
但只有这些数据结构才能被解构吗，还是可以用某种方式扩展其使用范围？
而且，它实际是怎么工作的？
是不是有什么魔法在里面，得以写些类似下面的代码？

 case class User(firstName: String, lastName: String, score: Int)
 def advance(xs: List[User]) = xs match {
   case User(_, _, score1) :: User(_, _, score2) :: _ => score1 - score2
   case _ => 0
 }

事实证明没有什么魔法，这都归功于提取器。

提取器使用最为广泛的使用有着与 构造器 相反的效果：
构造器从给定的参数列表创建一个对象，
而提取器却是从传递给它的对象中提取出构造该对象的参数。
Scala 标准库包含了一些预定义的提取器，我们会大致的了解一下它们。

样例类非常特殊，Scala会自动为其创建一个 伴生对象 ：
一个包含了 apply 和 unapply 方法的 单例对象 。
apply 方法用来创建样例类的实例，而 unapply 需要被伴生对象实现，以使其成为提取器。

第一个提取器

unapply 方法可能不止有一种方法签名，
不过，我们从只有最简单的开始，毕竟使用更广泛的还是只有一种方法签名的 unapply 。
假设要创建了一个 User 特质，有两个类继承自它，并且包含一个字段：

trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User

我们想在各自的伴生对象中为 FreeUser 和 PremiumUser 类实现提取器，
就像 Scala 为样例类所做的一样。
如果想让样例类只支持从给定对象中提取单个参数，那 unapply 方法的签名看起来应该是这个样子：

  def unapply(object: S): Option[T]

这个方法接受一个类型为 S 的对象，返回类型 T 的 Option ， T 就是要提取的参数类型。

在Scala中， Option 是 null 值的安全替代。
以后会有一个单独的章节来讲述它，不过现在，只需要知道，
unapply 方法要么返回 Some[T] （如果它能成功提取出参数），要么返回 None ，
None 表示参数不能被 unapply 具体实现中的任一提取规则所提取出。

下面的代码是我们的提取器：

trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User
object FreeUser {
  def unapply(user: FreeUser): Option[String] = Some(user.name)
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[String] = Some(user.name)
}

现在，可以在REPL中使用它：

scala> FreeUser.unapply(new FreeUser("Daniel"))
res0: Option[String] = Some(Daniel)

如果调用返回的结果是 Some[T] ，说明提取模式匹配成功，如果是 None ，说明模式不匹配。

一般不会直接调用它，因为用于提取器模式时，Scala 会隐式的调用提取器的 unapply 方法。

  val user: User = new PremiumUser("Daniel")
  user match {
    case FreeUser(name) => "Hello" + name
    case PremiumUser(name) => "Welcome back, dear" + name
  }

你会发现，两个提取器绝不会都返回 None 。
这个例子展示的提取器要比之前所见的更有意义。
如果你有一个类型不确定的对象，你可以同时检查其类型并解构。

这个例子里， FreeUser 模式并不会匹配，因为它接受的类型和我们传递给它的不一样。
这样一来， user 对象就会被传递给第二个模式，也就是 PremiumUser 伴生对象的 unapply 方法。
而这个模式会匹配成功，从而返回值就被绑定到 name 参数上。

在接下来的文章里，我们会看到一个并不总是返回 Some[T] 的提取器的例子。

提取多个值

现在，假设类有多个字段：

trait User {
  def name: String
  def score: Int
}
class FreeUser(
  val name: String,
  val score: Int,
  val upgradeProbability: Double
) extends User
class PremiumUser(
  val name: String,
  val score: Int
) extends User

如果提取器想解构出多个参数，那它的 unapply 方法应该有这样的签名：

def unapply(object: S): Option[(T1, ..., T2)]

这个方法接受类型为 S 的对象，返回类型参数为 TupleN 的 Option 实例，
TupleN 中的 N 是要提取的参数个数。

修改类之后，提取器也要做相应的修改：

trait User {
  def name: String
  def score: Int
}
class FreeUser(
  val name: String,
  val score: Int,
  val upgradeProbability: Double
) extends User
class PremiumUser(
  val name: String,
  val score: Int
) extends User
object FreeUser {
  def unapply(user: FreeUser): Option[(String, Int, Double)] =
    Some((user.name, user.score, user.upgradeProbability))
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[(String, Int)] =
    Some((user.name, user.score))
}

现在可以拿它来做模式匹配了：

val user: User = new FreeUser("Daniel", 3000, 0.7d)
user match {
  case FreeUser(name, _, p) =>
    if (p > 0.75) "$name, what can we do for you today?"
    else "Hello $name"
  case PremiumUser(name, _) =>
    "Welcome back, dear $name"
}

布尔提取器

有些时候，进行模式匹配并不是为了提取参数，而是为了检查其是否匹配。
这种情况下，第三种 unapply 方法签名（也是最后一种）就有用了，
这个方法接受 S 类型的对象，返回一个布尔值：

def unapply(object: S): Boolean

使用的时候，如果这个提取器返回 true ，模式会匹配成功，
否则，Scala 会尝试拿 object 匹配下一个模式。

上一个例子存在一些逻辑代码，用来检查一个免费用户有没有可能被说服去升级他的账户。
其实可以把这个逻辑放在一个单独的提取器中：

object premiumCandidate {
  def unapply(user: FreeUser): Boolean = user.upgradeProbability > 0.75
}

你会发现，提取器不一定非要在这个类的伴生对象中定义。
正如其定义一样，这个提取器的使用方法也很简单：

val user: User = new FreeUser("Daniel", 2500, 0.8d)
user match {
  case freeUser @ premiumCandidate() => initiateSpamProgram(freeUser)
  case _ => sendRegularNewsletter(user)
}

使用的时候，只需要把一个空的参数列表传递给提取器，因为它并不真的需要提取数据，自然也没必要绑定变量。

这个例子有一个看起来比较奇怪的地方：
我假设存在一个空想的 initiateSpamProgram 函数，其接受一个 FreeUser 对象作为参数。
模式可以与任何一种 User 类型的实例进行匹配，但 initiateSpamProgram 不行，
只有将实例强制转换为 FreeUser 类型， initiateSpamProgram 才能接受。

因为如此，Scala 的模式匹配也允许将提取器匹配成功的实例绑定到一个变量上，
这个变量有着与提取器所接受的对象相同的类型。这通过 @ 操作符实现。
premiumCandidate 接受 FreeUser 对象，因此，变量 freeUser 的类型也就是 FreeUser 。

布尔提取器的使用并没有那么频繁（就我自己的情况来说），但知道它存在也是很好的，
或迟或早，你会遇到一个使用布尔提取器的场景。

中缀表达方式

解构列表、流的方法与创建它们的方法类似，都是使用 cons 操作符： :: 、 #:: ，比如：

val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case first #:: second #:: _ => first - second
  case _ => -1
}

你可能会对这种做法产生困惑。
除了我们已经见过的提取器用法，Scala 还允许以中缀方式来使用提取器。
所以，我们可以写成 e(p1, p2) ，也可以写成 p1 e p2 ，
其中 e 是提取器， p1 、 p2 是要提取的参数。

同样，中缀操作方式的 head #:: tail 可以被写成 #::(head, tail) ，
提取器 PremiumUser 可以这样使用： name PremiumUser score 。
当然，这样做并没有什么实践意义。
一般来说，只有当一个提取器看起来真的像操作符，才推荐以中缀操作方式来使用它。
所以，列表和流的 cons 操作符一般使用中缀表达，而 PreimumUser 则不用。

进一步看流提取器

尽管 #:: 提取器在模式匹配中的使用并没有什么特殊的，
但是，为了更好的理解上面的代码，还是进一步来分析一下。
而且，这是一个很好的例子，根据要匹配的数据结构的状态，提取器很可能返回 None 。

如下是 Scala 2.9.2 源代码中完整的 #:: 提取器代码：

object #:: {
  def unapply[A](xs: Stream[A]): Option[(A, Stream[A]) =
    if (xs.isEmpty) None
    else Some((xs.head, xs.tail))
}

如果给定的流是空的，提取器就直接返回 None 。
因此， case head #:: tail 就不会匹配任何空的流。
否则，就会返回一个 Tuple2 ，其第一个元素是流的头，第二个元素是流的尾，尾本身又是一个流。
这样， case head #:: tail 就会匹配有一个或多个元素的流。
如果只有一个元素， tail 就会被绑定成空流。

为了理解流提取器是怎么在模式匹配中工作的，重写上面的例子，把它从中缀写法转成普通的提取器模式写法：

val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case #::(first, #::(second, _)) => first - second
  case _ => -1
}

首先为传递给模式匹配的初始流 xs 调用提取器。
由于提取器返回 Some(xs.head, xs.tail) ，从而 first 会绑定成 58，
xs 的尾会继续传递给提取器，提取器再一次被调用，返回首和尾， second 就被绑定成 43 ，
而尾就绑定到通配符 _ ，被直接扔掉了。

使用提取器

那到底该在什么时候使用、怎么使用自定义的提取器呢？尤其考虑到，使用样例类就能自动获得可用的提取器。

一些人指出，使用样例类、对样例类进行模式匹配打破了封装，
耦合了匹配数据和其具体实现的方式，这种批评通常是从面向对象的角度出发的。
如果想用 Scala 进行函数式编程，将样例类当作只包含纯数据（不包含行为）的
代数数据类型，那它非常适合。

通常，只有当从无法掌控的类型中提取数据，或者是需要其他进行模式匹配的方法时，才需要实现自己的提取器。

提取器的一种常见用法是从字符串中提取出有意义的值，
作为练习，想一想如何实现 URLExtractor 以匹配代表 URL 的字符串。

小结

在这本书的第一章中，我们学习了 Scala 模式匹配背后的提取器，
学会了如何实现自己的提取器，及其在模式中的使用是如何和实现联系在一起的。
但是这并不是提取器的全部，下一章，将会学习如何实现可提取可变个数参数的提取器。