由于样本类和构造器模式相关联,所以在模式匹配中常使用样本类做数据的解构和分析。有些情况下,或许希望能够在不创建关联的样本类的前提下编写出类似的模式匹配,此时抽取器(Extractor)可以用来定义与对象表达解耦的模式。
假设你需要分析一些代表email地址的字符串:对于给定的字符串,首先要判断它是否为email地址,如果是,再分析访问地址的用户名和域名。
def isEmail(s: String): Boolean
def domain(s: String): String
def user(s: String): String
这种方式有些笨拙,使用模式匹配的方式会有效解决这个问题。
s match{ caseEmail(user,domain)=>println (user +" AT "+ domain) case_=>println ("not an email address") }
但问题是String不是一个样本类,于是我们可以借助抽取器为内置的类型定义新的模式。
Scala里的抽取器就是具有名为unapply成员方法的对象。 unapply方法的目的是为了匹配并分解值,apply是其对偶方法,unapply逆转了apply的构建过程,将构建的对象进行分解。
针对email的例子,可以使用如下方式进行编写程序:
object EMail { def apply(user:String,domain:String) = user +"@"+ domain def unapply(str: String) :Option[(String,String)] ={ val parts = str split"@" if(parts.length==2) Some(parts(0),parts(1))elseNone } }
使用时是这样的:
scala>EMail.unapply("jasonding@gmail.com") res1:Option[(String,String)] =Some(("jasonding","gmail.com")) scala> EMail.unapply("Jason Ding") res2:Option[(String,String)] =None
在某种程度上来说,unapply和apply的作用相反,apply方法把两个字符串参数变成一个Email地址,而unapply方法反向变换,把一个字符串分解成两个部分:用户名和域名。unapply方法必须处理不能把一个字符串分解成两部分的情况,这也是为什么这里unapply方法返回Option类型的原因。
apply方法被称为注入方法,因为它可以传入一些参数并生成指定子集的元素。unapply方法被称为抽取方法,因为它可以传入相同子集的元素并抽取其中的部分。注入方法和抽取方法常常处于同一个对象中,因为如此一来,你可以把对象名既当做构造器也当做模式用,这是对使用样本类作模式匹配的惯例的模仿。
上一小节例子中unapply方法在匹配成功时返回一个二元组。这可以很容易的推广到多于两个变量的情况。为了绑定N个变量,unapply方法可以返回一个 N元组,封装在Some中 。
对于一个只绑定一个变量的情况,为返回一个变量,该变量直接封装在Some中返回。
objectTwice{ defapply(s:String) = s + s defunapply(s:String):Option[String] ={ vallength=s.length/2 valhalf = s.substring(0,length) if(half == s.substring(length)) Some(half)elseNone } }
一个Extractor也可以绑定任何变量,这种情况下可以返回true和false代表匹配成功与否。比如下面的例子匹配一个字符串是否都是大写字母:
object UpperCase { defunapply(s:String):Boolean = s.toUpperCase ==s }
之后可以利用上面定义的Twice和UpperCase组合构造组合的模式定义:
def userTwiceUpper(s:String) = s match{ caseEMail(Twice(x @ UpperCase()),domain)=> "match:"+ x +" in domain "+ domain case_=>"no match" }
使用效果:
scala>userTwiceUpper("DIDI@hotmail.com") res1:String=match:DIindomain hotmail.com scala> userTwiceUpper("DIDO@hotmail.com") res2:String= no match scala> userTwiceUpper("didi@hotmail.com") res3:String= no match
以 x @ UpperCase()
形式吧变量与UpperCase()模式进行变量绑定。
针对这种变长类型的匹配,Scala定义了一个 unapplySeq
方法来支持这种用法,例如:
object Domain{ defapply(parts:String *):String = parts.reverse.mkString(".") defunapplySeq(whole:String):Option[Seq[String]] = Some(whole.split("//.").reverse) }
对象Domain定义unapplySeq方法,首先以“.”分割字符串,Split使用正规表达式,因此.需要使用/转义。unapplySeq结果返回一个封装在Some的Seq数据。
然后可以使用Domain抽取器来获取Email地址更详细的信息。比如查找用户名为“tom”,域名为某些含“com”的地址。
defisTomDotCom(s:String):Boolean =s match{ case EMail("tom",Domain("com",_*)) => true case _ => false }
测试结果:
scala>isTomDotCom("tom@sun.com") res0:Boolean=true scala> isTomDotCom("peter@sun.com") res1:Boolean=false scala> isTomDotCom("tom@acm.org") res2:Boolean=false
使用unapplySeq也支持返回一部分固定长度的变量加上后面变长的变量,这个返回值可以表示成一多元组,可变的部分放在最后。比如:
object ExpendedEMail{ def unapplySeq(email: String) :Option[(String,Seq[String])] ={ val parts = email split"@" if(parts.length==2) Some(parts(0),parts(1).split("//.").reverse) else None } }
解构列表、流的方法与创建它们的方法类似,都是使用 cons 操作符: :: 、 #:: ,比如:
val xs = 58#:: 43 #:: 93 #:: Stream.empty xs match { casefirst#:: second #:: _ => first - second case_ => -1 }
Scala允许以中缀方式来使用提取器。 所以,我们可以写成 e(p1, p2)
,也可以写成 p1 e p2
,其中e是抽取器,p1、p2是要提取的参数。
同样,中缀操作方式的 head #:: tail
可以被写成 #::(head, tail)
。一般来说,只有当一个抽取器看起来真的像操作符,才推荐以中缀操作方式来使用它。所以,列表和流的cons操作符一般使用中缀表达。
Scala的 #::
提取器代码:
object #:: { defunapply[A](xs: Stream[A]):Option[(A, Stream[A]) = if(xs.isEmpty)None elseSome((xs.head, xs.tail)) }
如果给定的流是空的,抽取器就直接返回None。因此,case head #:: tail就不会匹配任何空的流。否则,就会返回一个Tuple2,其第一个元素是流的头,第二个元素是流的尾,尾本身又是一个流。这样,case head #:: tail就会匹配有一个或多个元素的流。如果只有一个元素,tail就会被绑定成空流。
抽取器和样本类都可以用来做模式匹配,进行数据的结构和分析。但这两个概念有各自的特点。
样本类的缺点是它暴露了数据的具体表达方式,如果匹配到样本类的构造器形式,就知道了选择器表达式实际上是特定样本类的实例。抽取器截断了数据表达与模式之间的联系,实现了 表征独立 (representation independence,让模式与被选择对象的数据类型之间毫无关系)
。在大型开发系统中,表征独立非常重要,因为这可以让修改部件的实现类型不会影响部件的使用者。
如果部件已经定义并导出了一套样本类的话,因为客户代码可能已经包含了对这些样本类的模式匹配,重命名某些样本类或修改类层级都将影响客户代码。但是, 抽取器不会出现类似的问题,因为它们代表了数据表现和客户观察方式之间的间接适配层,你仍然可以修改类型的具体实现,只要对抽取器做更新即可 。
首先,样本类更易于建立和定义、需要更少的代码。
其次,它们通常能实现比抽取器更为高效的模式匹配,因为Scala编译器对于样本类模式的优化远胜于对抽取器模式的优化。这是由于样本类的机制是固定的,但抽取器的unapply和unapplySeq方法几乎能做任何事情。
第三,如果样本类继承自sealed基类,那么Scala编译器将采用穷举法检测模式匹配并在模式没有覆盖某种可能的组合值情况下报错,但对于抽取器来说不存在这种穷举检查。
如果编写的代码是封闭的应用,那么样本类通常更为合适,因为它们更简洁,编写速度更快,而且有静态检查。
如果你决定之后要修改类层级,应用程序需要重构,并且如果你需要把类型暴露给未知的客户,那么抽取器更为合适,因为它们能保持表征独立。
实际上,可以始终以样本类开始,然后如果有新需求,将其改为抽取器。因为抽取器模式与样本类模式在Scala中看上去完全一致,所以你的客户代码中的模式匹配还将能够继续工作。
《Scala编程》
转载请注明作者Jason Ding及其出处
jasonding.top
Github博客主页(http://blog.jasonding.top/)
CSDN博客(http://blog.csdn.net/jasonding1354)
简书主页(http://www.jianshu.com/users/2bd9b48f6ea8/latest_articles)
Google搜索jasonding1354进入我的博客主页