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
2
3

// 作用在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()的函数签名十分类似：

1
2
3

// 作用在Optional<T>上的方法
    map( transform: T ->          U  ) -> Optional<U>
flatMap( transform: T -> Optional<U> ) -> Optional<U>

是不是很像？

作用在可选类型上的 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)：

let icon: UIImage?
if let iconName = itemDesc["icon"] as? String {
  icon = UIImage(named: iconName)
} else {
  icon = nil
}

但是对于一个如此简单的操作来说代码量太大。

之前的一个例子中我们用了另外一种(很不优雅的)方式，使用nil-联合操作符??。

1 2	let iconName = itemDesc["icon"] as? String let icon = UIImage(named: iconName ?? "")

这么做是可以，但是之所以能够成功，是因为当iconName是nil时，我们实际上是使用了UIImage(named: "")的初始化方法，这个初始化方法在传入空字符串时，会返回nil。但是这样的解决办法不是很好，因为我们是依赖于该初始化方法的特性（传入空字符串时，会返回nil）来实现的。

来用 map 吧

那么为什么不用map呢？本质上，我们是想要在Optional<String>不是nil的时候将其解包，把里面的值转换成一个UIImage对象然后把这个UIImage返回，这不就是一个绝佳的用例么？

试试看：

1 2	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() 来帮忙了

flatMap()与map类似，但是做的是一个T->U?的转换(不是T->U)，它把结果“扁平化(顾名思义)”成一个单重的可选类型。这恰恰就是我们所需要的！

1 2	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)初始化方法成功的情况下才是一个非空值。

和使用??欺骗初始化方法相比，这么做更好，更地道。

把 init 当闭包来用

更进一步，由于现在 Xcode 7 可以通过类型的.init属性暴露该类型的构造器(constructors)，上面的代码还能写的更加紧凑。

这意味着UIImage.init本质上就已经是一个接收String并返回UIImage?的方法了，所以我们可以把它直接当成参数来调用flatMap，不用把它再包进一个闭包里！

1 2	let iconName = itemDesc["icon"] as? String item.icon = iconName.flatMap(UIImage.init)

哇哦！太魔幻了！

好了，有人说这么写很难读懂，为了让代码更明了更清晰，在这里还是更喜欢用一个显式闭包。但是这只是关乎个人偏好，并且知道这么做可行也是好事。

最终的Swift代码

下面就是将本课所学应用到之前代码里的样子：

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)
    }
  }
}

回头看一眼我们的 ObjC 代码

花一点儿时间比较一下我们最终的 Swift 代码和最开始的ObjC代码。我们着实改了很大一部分内容。

如果你仔细看一下 ObjC 和 Swift 代码，会发现 Swift 的代码量并不是那么少(ObjC 是 5+15 LoC1，对比 Swift 的 19 LoC)，但是安全性高了太多。

尤其是我们使用的guard，try?和as?会迫使我们去检查所有类型是否都如所期，ObjC 代码不会关心这些，因此可能崩溃