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