作者:Olivier Halligon, 原文链接 ,原文日期:2015-10-11
译者: ray16897188 ;校对: Prayer ;定稿: numbbbbb
系列文章地址:
在本系列之前的文章中我们学到了如何使用 map
和 flatMap
来操作数组(arrays)。今天我们继续研究如何对可选类型(Optionals)以及很多其他类型使用 map
和 flatMap
。
回顾一下,学完前面的文章后我们已经知道, Array<T>
对应的 map()
和 flatMap()
函数签名是:
// 作用在Array<T>上的方法
map( transform: T -> U ) -> Array<U>
flatMap( transform: T -> Array<U> ) -> Array<U>
意思是你可以用一个给定的 transform: T->U
将一个元素类型是 T
的数组转换成一个元素类型是 U
的数组。对 Array<T>
调用 map( transform: T->U )
方法就会返回一个 Array<U>
,就这么简单。
嗯,不出意外,对于 Optional<T>
来说, map()
和 flatMap()
的函数签名十分类似:
// 作用在Optional<T>上的方法
map( transform: T -> U ) -> Optional<U>
flatMap( transform: T -> Optional<U> ) -> Optional<U>
是不是很像?
那么 map
方法到底对 Optional<T>
类型(也叫做 T?
)做了什么?
其实很简单:和作用在 Array<T>
上的一样, map
方法将 Optional<T>
中的内容取出来,用指定的 transform: T->U
方法做出转换,然后把结果包装成一个新的 Optional<U>
。
如果细想一下,这和 Array<T>.map
做的事情十分相似:这个方法对 Array<T>
(与之相应的是 Optional<T>
)中的每个元素使用 transform
函数转换,并将转换过的值封装在一个新的 Array<U>
中(与之相应的是 Optional<U>
),作为结果返回。
那么这对我们一直在做的示例代码有什么帮助?
在 我们最新版代码中 ,有一个 String?
类型的 itemDesc["icon"]
,我们当时想把它转换成一个 UIImage
;但是 UIImage(named:)
要求传入一个 String
型的参数,而不是 String?
型,所以我们需要在可选型中确实有值时(非 nil
)将内部的 String
值传入。
一种解决方案是使用可选绑定(Optional Binding):
let icon: UIImage?
if let iconName = itemDesc["icon"] as? String {
icon = UIImage(named: iconName)
} else {
icon = nil
}
但是对于一个如此简单的操作来说代码量太大。
之前的一个例子中我们用了另外一种(很不优雅的)方式,使用 nil
-联合操作符 ??
。
let iconName = itemDesc["icon"] as? String
let icon = UIImage(named: iconName ?? "")
这么做是可以,但是之所以能够成功,是因为当 iconName
是 nil
时,我们实际上是使用了 UIImage(named: "")
的初始化方法,这个初始化方法在传入空字符串时,会返回 nil
。但是这样的解决办法不是很好,因为我们是依赖于该初始化方法的特性(传入空字符串时,会返回 nil
)来实现的。
那么为什么不用 map
呢?本质上,我们是想要在 Optional<String>
不是 nil
的时候将其解包,把里面的值转换成一个 UIImage
对象然后把这个 UIImage
返回,这不就是一个绝佳的用例么?
试试看:
let iconName = itemDesc["icon"] as? String
item.icon = iconName.map { imageName in UIImage(named: imageName) }
等会儿…. 编译不通过。能猜出为什么吗?
上面的代码中的问题是 UIImage(named: …)
也返回一个可选类型:如果对给定的 name
没有相应的图片,就不能创建出一个 UIImage
,所以这种情况下该初始化方法为 可失败的(failable) ,并返回 nil
,是完全合理的。
于是问题就在于我们给 map
的这个闭包用一个 String
作为参数而返回…一个 UIImage?
类型——因为图片的初始化方法是 可失败的 ,会返回 nil
。再看一下 map
方法的签名,它想要的是一个 T->U
类型的闭包,这个闭包会返回一个 U?
类型。我们的例子中, U
代表 UIImage?
的话,整个 map
表达式会返回一个 U?
类型,也就是…一个 UIImage??
类型…是的,一个双重可选类型,吓死宝宝了!
flatMap()
与 map
类似,但是做的是一个 T->U?
的转换(不是 T->U
),它把结果“扁平化(顾名思义)”成一个单重的可选类型。这恰恰就是我们所需要的!
let iconName = itemDesc["icon"] as? String
item.icon = iconName.flatMap { imageName in UIImage(named: imageName) }
实际中 flatMap
做了如下工作:
iconName
是 nil
的话,它就直接返回 nil
(但返回类型还是 UIImage?
) iconName
不是 nil
,它就把 transform
作用到 iconName
的实际的值上,尝试用这个 String
创建一个 UIImage
并将结果返回——结果本身已经是一个 UIImage?
类型,因此如果 UIImage
初始化方法失败的话,返回结果就是 nil
。 简而言之, item.icon
只会在 itemDesc["icon"] as? String
非空、并且 UIImage(named: imageName)
初始化方法成功的情况下才是一个非空值。
和使用 ??
欺骗初始化方法相比,这么做更好,更地道。
更进一步,由于现在 Xcode 7 可以通过类型的 .init
属性暴露该类型的构造器(constructors),上面的代码还能写的更加紧凑。
这意味着 UIImage.init
本质上就已经是一个接收 String
并返回 UIImage?
的方法了,所以我们可以把它直接当成参数来调用 flatMap
,不用把它再包进一个闭包里!
let iconName = itemDesc["icon"] as? String
item.icon = iconName.flatMap(UIImage.init)
哇哦!太魔幻了!
好了,有人说这么写很难读懂,为了让代码更明了更清晰,在这里还是更喜欢用一个显式闭包。但是这只是关乎个人偏好,并且知道这么做可行也是好事。
下面就是将本课所学应用到之前代码里的样子:
struct ListItem {
var icon: UIImage?
var title: String
var url: NSURL
static func listItemsFromJSONData(jsonData: NSData?) -> [ListItem] {
guard let jsonData = jsonData,
let json = try? NSJSONSerialization.JSONObjectWithData(jsonData, options: []),
let jsonItems = json as? Array<NSDictionary> else { return [] }
return jsonItems.flatMap { (itemDesc: NSDictionary) -> ListItem? in
guard let title = itemDesc["title"] as? String,
let urlString = itemDesc["url"] as? String,
let url = NSURL(string: urlString)
else { return nil }
let iconName = itemDesc["icon"] as? String
let icon = iconName.flatMap { UIImage(named: $0) }
return ListItem(icon: icon, title: title, url: url)
}
}
}
花一点儿时间比较一下我们最终的 Swift 代码和 最开始的ObjC代码 。我们着实改了很大一部分内容。
如果你仔细看一下 ObjC 和 Swift 代码,会发现 Swift 的代码量并不是那么少(ObjC 是 5+15 LoC 1 ,对比 Swift 的 19 LoC),但是 安全性高了太多 。
尤其是我们使用的 guard
, try?
和 as?
会迫使我们去检查所有类型是否都如所期,ObjC 代码不会关心这些,因此可能崩溃。所以虽然代码量相当,但 ObjC 代码更危险。
通过本系列文章,我希望你能够意识到:不要尝试将你的 ObjC 代码直译成 Swift。相反,你要去重新考虑一下你的代码,重新想象一下你的代码。从一个空白状态开始,脑中秉持着 Swift 的理念重写你的代码总会比你把 ObjC 代码直译过来要好。
我没说过这是件容易的事儿。当你已经习惯了用 ObjC 写代码,熟悉了它的模式和写代码的方式的话,做出思维上的改变会需要一些时间。但是这绝对有更多的好处。
以上就是 Swift 编程思想系列的最后一部分内容 2 。现在你要开始为新 Swift 项目发狂了,把 Swift 编程思想全部贯彻到你的脑海中。
祝用 Swift 编程愉快,并且…