原文地址:
http://blog.sina.com.cn/s/blog_68af3f090100qkt8.html
对于学习 Scala 的 Java™ 开发人员来说,对象是一个比较自然、简单的入口点。在 本系列 前几期文章中,我介绍了 Scala 中一些面向对象的编程方法,这些方法实际上与 Java 编程的区别不是很大。我还向您展示了 Scala 如何重新应用传统的面向对象概念,找到其缺点,并根据 21 世纪的新需求重新加以改造。Scala 一直隐藏的一些重要内容将要现身:Scala 也是一种函数语言(这里的函数性是与其他 dys 函数语言相对而言的)。
Scala 的面向函数性非常值得探讨,这不仅是因为已经研究完了对象内容。Scala 中的函数编程将提供一些新的设计结构和理念以及一些内置构造,它们使某些场景(例如并发性)的编程变得非常简单。
C# 2.0 可变为 null 值的类型其他语言已试图通过各种方法解决 “可 null 值化” 问题:C++ 一直都忽略了这个问题,直至最后确定 null 和 0 是不同的值。Java 语言仍然没有彻底解决这个问题,而是依赖于自动装箱(autobox)— 将原语类型自动转换为它们的包装器对象(在 1.1 以后引入)— 帮助 Java 程序员解决问题。一些模式爱好者建议每种类型都应该有一个对应的 “Null Object”,即将自己的所有方法重写为不执行任何操作的类型(实际上是子类型)的实例 — 实践证明这需要大量工作。C# 1.0 发布后,C# 设计者决定采取一种完全不同的方法解决 null 值化问题。
C# 2.0 引入了可变为 null 值的类型 的概念,重要的是添加了语法支持,认为任何特定值类型(基本指原语类型)都可以通过将 null 封装到一个泛型/模板类 Nullable<T>,从而提供 null 支持。Nullable<T> 本身是在类型声明中通过 ? 修饰符号引入。因此,int? 表示一个整数也可能为 null。
表面上看,这似乎很合理,但是事情很快就变得复杂起来。int 和 int? 是否应该被视为可兼容类型,如果是的话,什么时候将 int 提升为 int?,反之呢?当将 int 添加到 int? 会发生什么,结果会是 null 吗?这类问题等等。随后类型系统进行了一些重要的调整,可变为 null 值的类型随后包含到了 2.0 中 — 而 C# 程序员几乎完全忽略了它们。
回顾一下 Option 类型的函数方法,它使 Option[T] 和 Int 之间的界限变得很清晰,看上去要比其他方法更加简单。在那些围绕可变为 null 值类型的反直觉(counterintuitive)提升规则之间进行比较时,尤其如此。(函数领域对该问题近二十年的思考是值得的)。要使用 Option[T] 必须付出一些努力,但是总的来说,它产生了更清晰的代码和期望。
.本月,您将首次进入 Scala 的函数编程领域,查看大多数函数语言中常见的四种类型:列表(list)、元组(tuple)、集合(set)和 Option 类型。您还将了解 Scala 的数组,后者对其他函数语言来说十分新鲜。 这些类型都提出了编写代码的新方式。当结合传统面向对象特性时,可以生成十分简洁的结果。
使用 Option(s)
在什么情况下,“无” 并不代表 “什么也没有”?当它为 0 的时候,与 null 有什么关系。
对于我们大多数人都非常熟悉的概念,要在软件中表示为 “无” 是一件十分困难的事。例如,看看 C++ 社区中围绕 NULL 和 0 进行的激烈讨论,或是 SQL 社区围绕 NULL 列值展开的争论,便可知晓一二。 NULL 或 null 对于大多数程序员来说都表示 “无”,但是这在 Java 语言中引出了一些特殊问题。
考虑一个简单操作,该操作可以从一些位于内存或磁盘的数据库查找程序员的薪资:API 允许调用者传入一个包含程序员名字的 String,这会返回什么呢?从建模角度来看,它应该返回一个 Int,表示程序员的年薪;但是这里有一个问题,如果程序员不在数据库中(可能根本没有雇用她,或者已经被解雇,要不就是输错了名字……),那么应该返回 什么。如果返回类型是 Int,则不能返回 null,这个 “标志” 通常表示没有在数据库中找到该用户(您可能认为应该抛出一个异常,但是大多数时候数据库丢失值并不能视为异常,因此不应该在这里抛出异常)。
在 Java 代码中,我们最终将方法标记为返回 java.lang.Integer,这迫使调用者知道方法可以返回 null。自然,我们可以依靠程序员来全面归档这个场景,还可以依赖程序员读取 精心准备的文档。这类似于:我们可以要求经理倾听我们反对他们要求的不可能完成的项目期限,然后经理再进一步把我们的反对传达给上司和用户。
Scala 提供了一种普通的函数方法,打破了这一僵局。在某些方面,Option 类型或 Option[T],并不重视描述。它是一个具有两个子类 Some[T] 和 None 的泛型类,用来表示 “无值” 的可能性,而不需要语言类型系统大费周折地支持这个概念。实际上,使用 Option[T] 类型可以使问题更加清晰(下一节将用到)。
在使用 Option[T] 时,关键的一点是认识到它实质上是一个大小为 “1” 的强类型集合,使用一个不同的值 None 表示 “nothing” 值的可能性。因此,在这里方法没有返回 null 表示没有找到数据,而是进行声明以返回 Option[T],其中 T 是返回的原始类型。那么,对于没有查找到数据的场景,只需返回 None,如下所示:
清单 1. 准备好踢足球了吗?
Java代码 收藏代码
@Test def simpleOptionTest =
{
val footballTeamsAFCEast =
Map("New England" -> "Patriots",
"New York" -> "Jets",
"Buffalo" -> "Bills",
"Miami" -> "Dolphins",
"Los Angeles" -> null)
assertEquals(footballTeamsAFCEast.get("Miami"), Some("Dolphins"))
assertEquals(footballTeamsAFCEast.get("Miami").get(), "Dolphins")
assertEquals(footballTeamsAFCEast.get("Los Angeles"), Some(null))
assertEquals(footballTeamsAFCEast.get("Sacramento"), None)
}
注意,Scala Map 中 get 的返回值实际上并不对应于传递的键。相反,它是一个 Option[T] 实例,可以是与某个值有关的 Some(),也可以是 None,因此可以很清晰地表示没有在 map 中找到键。如果它可以表示 map 上存在某个键,但是有对应的 null 值,这一点特别重要了。比如清单 1 中 Los Angeles 键。
通常,当处理 Option[T] 时,程序员将使用模式匹配,这是一个非常函数化的概念,它允许有效地 “启用” 类型和/或值,更不用说在定义中将值绑定到变量、在 Some() 和 None 之间切换,以及提取 Some 的值(而不需要调用麻烦的 get() 方法)。清单 2 展示了 Scala 的模式匹配:
清单 2. 巧妙的模式匹配
Java代码 收藏代码
@Test def optionWithPM =
{
val footballTeamsAFCEast =
Map("New England" -> "Patriots",
"New York" -> "Jets",
"Buffalo" -> "Bills",
"Miami" -> "Dolphins")
def show(value : Option[String]) =
{
value match
{
case Some(x) => x
case None => "No team found"