提取器

在 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会自动为其创建一个 伴生对象 : 一个包含了 applyunapply 方法的 单例对象apply 方法用来创建样例类的实例,而 unapply 需要被伴生对象实现,以使其成为提取器。

第一个提取器

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

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

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

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

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

在Scala中, Optionnull 值的安全替代。 以后会有一个单独的章节来讲述它,不过现在,只需要知道, unapply 方法要么返回 Some[T] (如果它能成功提取出参数),要么返回 NoneNone 表示参数不能被 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 的对象,返回类型参数为 TupleNOption 实例, 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 是提取器, p1p2 是要提取的参数。

同样,中缀操作方式的 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 模式匹配背后的提取器, 学会了如何实现自己的提取器,及其在模式中的使用是如何和实现联系在一起的。 但是这并不是提取器的全部,下一章,将会学习如何实现可提取可变个数参数的提取器。

results matching ""

    No results matching ""