Scala模式匹配简述

什么是匹配模式？

模式匹配并不很新，（上世纪）七十年代中期就已经有语言采用。据我所知，第一种语言是ML，但可能也有更早的语言支持。它在许多函数式语言中都算是标准功能，包括ML、Caml、Erlang、以及Haskell。

那么什么是模式匹配呢？它可以让你给一个值匹配多种情况，有点像Java中的switch语句。但它不仅可以像switch语句一样用来匹配数字，还可以匹配对象的内在构建形式。

比如，Scala中的List存在两种情况：要么是空List，写做Nil；要么由一个head元素紧接着另一List tail组成。有了模式匹配，你可以询问：给定的List是空List吗？只要编写case Nil、箭头(=>)以及后续表达式即可：

case Nil => // 后续表达式

你还可以询问：它是非空List吗？只要编写case x :: xs、箭头、以及后续表达式即可：

case x :: xs => // 后续表达式

双冒号（::）表示cons操作符；x表示List的首元素，xs表示剩余部分。于是，模式匹配会首先区分List是否为空。而如果List非空，它会把List的首元素命名为x然后把List剩余部分命名为xs。接下来，这些变量可以被箭头右侧表达式所用。（参见示例1）

示例1：match表达式

list match { 
    case Nil => "was an empty list" 
    case car :: cdr => "head was " + car + ", tail was " + cdr
}

如果list不为空，将匹配到第二种情况，List首元素将赋值给x，而列表剩余部分赋值给xs。接下来，这些变量将被箭头符号右侧的字符串连接表达式所用。例如，如果list内容是List("hello", "world")，那么匹配表达式的结果将是字符串"head was hello, tail was List(world)"。

上例的模式非常简单。但实际上模式还支持嵌套，类似表达式的嵌套，能让你编写层数很深的模式。总的来说，亮点在于，模式和表达式看起来很像。模式本质上和表达式属于完全一类东西，看上去就像构造表达式一样，可以用来构造复杂树状对象，但却不需要编写new。事实上，在Scala中，该对象构造时一样不需要new。然后你可以在某些位置填上占位变量，对应树对象中实际存在的值。（参见示例2）

示例2：嵌套模式的match表达式

object match { 
    case Address(Name(first, last), street, city, state, zip) => println(last + ", " + zip) 
    case _ => println("not an address") // 默认情况
}

在第一种情况下，模式Name(first, last)嵌在模式Address(...)中。last放在了Name构造函数内，可以“提取”出值，因而，可供箭头右边的表达式使用。

因为匹配是发生在运行期的，而且JVM中泛型的类型信息会被擦掉(跟Java里范型一样不能匹配)。

case m: Map[String, Int] => ...  // 不行，类型不起作用
case m: Map[_, _] => ...  // 匹配通用的Map，OK

但对于数组来说，类型信息是完好的，所以可以在Array上匹配。

对于嵌套结构，举例就能一目了然。

abstarct class Item
case class Article(description: String, price: Double) extends Item
case class Bundle(description: String, price: Double, items: Item*) extends Item
 
Bundle("Father's day special", 20.0, 
  Article("Scala for the Impatient", 39.95),
  Bundle("Anchor Distillery Sampler", 10.0,
    Article("Old Potrero Straight Rye Whisky", 79.95),
    Article("Junipero Gin", 32.95)
  )
)

模式可以匹配到特定的嵌套：

case Bundle(_, _, Article(descr, _), _*) => ...

上面的代码中descr这个变量被绑定到第一个Article的description。另外还可以使用@来将值绑定到变量：

// art被绑定为第一个Article，rest是剩余的Item序列
case Bundle(_, _, art @ Article(_, _), rest @ _*) => ...

样例类
样例类是种特殊的类，经过优化以用于模式匹配。

abstract class Amount
// 继承了普通类的两个样例类
case class Dollar(value: Double) extends Amount
case class Currency(value: Double, unit: String) extends Amount
 
// 样例对象
case object Nothing extends Amount

使用：

amt match {
  case Dollar(v) => "$" + v
  case Currency(_, u) => "Oh noes, I got " + u
  case Nothing => ""  // 样例对象没有()
}

在声明样例类时，下面的过程自动发生了：
构造器的每个参数都成为val，除非显式被声明为var，但是并不推荐这么做；
在伴生对象中提供了apply方法，所以可以不使用new关键字就可构建对象；
提供unapply方法使模式匹配可以工作；
生成toString、equals、hashCode和copy方法，除非显示给出这些方法的定义。
除了上述之外，样例类和其他类型完全一样，方法字段等。

密封类
当使用样例类来做模式匹配时，如果要让编译器确保已经列出所有可能的选择，可以将样例类的通用超类声明为sealed。
密封类的所有子类都必须在与该密封类相同的文件中定义。
如果某个类是密封的，那么在编译期所有的子类是可知的，因而可以检查模式语句的完整性。
让所有同一组的样例类都扩展某个密封的类或特质是个好的做法。

模式匹配的目的

那么，为什么你需要模式匹配？我们每个人都有复杂的数据。如果我们坚持严格的面向对象的风格，那么我们并不希望直接访问数据内部的树状结构。相反，我们希望调用方法，然后在方法中访问。如果我们能够这样做，那么我们就再也不需要模式匹配了，因为这些方法已经提供了我们需要的功能。但很多情况下，对象并不提供我们需要的方法，而且我们无法（或者不愿）向这些对象添加方法。

例如XML。如果给你一棵XML树，那么树就只是单纯的数据。要么是节点，要么是节点的序列。XML是一种非常通用的数据表现形式。例如，DOM本质上只是节点的数组，其中每个节点的类型都未知。现在我们设想一下，如果把XML树转换到某种更强的框架中，可以给你一个列表，容纳各种不同类型的对象。组成列表的元素可能包括诸如电话号码、备忘录或地址等。如果你想以静态类型的方式获取所有这些东西，就会遇上一个问题：你不知道每个元素的类型。在传统面向对象的编程语言中，唯一可行方式是，编写一大堆instanceof检测，一一测试每个元素是PhoneNumber实例、Memo实例，还是其他实例。一旦这些instanceof语句之一检测成功，你还需要进行类型转换。上述做法相当丑陋和笨拙，有了模式匹配就能避免了。模式匹配能以更安全、更自然的方式完成相同功能。

从本质上讲，当你从外部取得具有结构的对象图时，模式匹配就必不可少。你会在若干情况下遇到这种现象，XML是其中之一。各种从文本解析而来的数据，都属于这一类。例如，有一种典型情况下模式匹配必不可少，即，处理编译器中的抽象语法树的情况。如果你要对表达式进行化简操作，表达式会被表示为树，你需要通过模式匹配对这些树进行提取操作。类似那样的情况还有许多。遇到这些情况时，模式匹配真的必不可少。