Swift 编程思想，第三部分：结构体和类

轩辕小羽
1,526 阅读6分钟
原文链接： swift.gg

作者：Olivier Halligon，原文链接，原文日期：2015-10-03
译者：ray16897188；校对：pmst；定稿：小锅

系列文章地址：

继续说咱的”Swift编程思想系列”，今天我们将会做一些小小的改动，使用 struct（结构体） 来使代码得到进一步的简化。

前面的内容

在这个系列之前的一篇文章里我们学到了对数组(arrays)使用 map 和 flatMap，消除了中间变量(intermediate variables)形式的状态性(statefulness)，并使用了一些函数式编程1。

下面是我们之前收工时的代码，贴在这里回顾一下：

class ListItem {
    var icon: UIImage?
    var title: String = ""
    var url: NSURL!

    static func listItemsFromJSONData(jsonData: NSData?) -> [ListItem] {
        guard let nonNilJsonData = jsonData,
            let json = try? NSJSONSerialization.JSONObjectWithData(nonNilJsonData, options: []),
            let jsonItems = json as? Array
            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 li = ListItem()
            if let icon = itemDesc["icon"] as? String {
                li.icon = UIImage(named: icon)
            }
            li.title = title
            li.url = url
            return li
        }
    }
}

今天我们将对例子进行相当简单的改动，使得代码更加精简以及显得”雨燕风”(Swift-er)。

Struct相比Class

正如上面代码所示，首先考虑使用类(class)是Swift初学者经常犯的一个错误。不过这可以理解，因为在ObjC中我们满世界的用class。

使用class不是什么原则性错误。在Swift中当然也可以继续用。但是Swift的结构体(struct)比它 C 前身的结构体要强大很多：它们不再只是存储一系列的值。

Swift的结构体(structs)和类(Class)具有相同的功能 - 除了继承 - 结构体是值类型(value-types) (所以每一次变量赋值都是通过值拷贝的形式，与Int类型很相像)，而类属于引用类型(reference-types)，以引用方式传递而非值拷贝，这和Objective-C(以及OC中无处不在的难看的*，也代表着引用)中一样。

我不会在这里展开长篇论述，讨论结构体、值类型和类、引用类型相比较孰胜孰劣：我还是直接强烈建议你看一下Andy Matuschak对此话题的精彩论述。我不需要自己再解释了，Andy说的比我好。

把我们的class转换成struct

在我们的例子中，使用一个结构体看起来更为合适，因为它保存了一些值，并且并不会要对它们做什么改变(更适合拷贝而非引用)。案例中，我们把它用作一个菜单栏的数据源，一旦创建就不再对其更改，所以这也是使用结构体更为合理的一个场景。

还有，这里把class迁移成struct的另一个优势是，如果struct没有定义适合一个构造器，则它会生成一个默认的隐式构造器：所以我们可以非常容易的用默认构造器ListItem(icon: …, title: …, url: …)去创建一个ListItem。

最后一项要点是，由于在之前的文章中我们消除了数据损坏的问题，有问题的ListItem就不会被创建出来了，我们就可以把title的默认值""消除掉，但更重要的是我们就能把NSURL!转换成NSURL!去拯救最后一匹小马🐴2。

转换之后的代码如下：

struct ListItem {
    var icon: UIImage?
    var title: String
    var url: NSURL

    static func listItemsFromJSONData(jsonData: NSData?) -> [ListItem] {
        guard let nonNilJsonData = jsonData,
            let json = try? NSJSONSerialization.JSONObjectWithData(nonNilJsonData, options: []),
            let jsonItems = json as? Array 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 = UIImage(named: iconName ?? "")
            return ListItem(icon: icon, title: title, url: url)
        }
    }
}

现在当一切都就绪之后，我们只在最后一步创建才创建出ListItem实例，如果你不提供任何init方法的话struct会提供一个默认的init方法为它自己的参数段传值。用class的版本可以做相同的事，但是用class的话我们得自己声明init。

联合操作符(Coalescing operator)

上面的例子中我还用了一个新的小技巧，使用??操作符让iconName在是nil的时候给出一个默认值。

??操作符和ObjC的opt ?: val表达式很像，了解它的人都知道：opt ?? val如果在opt非空的时候返回它的值，如果是nil的话会返回val。这意味着如果opt是T?类型，val则必须是T类型，整个表达式的结果也会是T类型。

那么这里的iconName ?? ""会允许我们在iconName为nil的时候使用一个空字符""的图片名称，于是这里会有一个nil的UIImage，并且icon也会是nil。

⚠️注意⚠️：将一个为nil的iconName和一个nil的UIImage作为结果来处理，这并不是最佳的、最简洁的做法。实际上使用一个假的""名字来获得一个空图片看起来有点儿难看，还有点儿欺骗的意味。但是这是给你展示??操作符存在感的一个场合…嘿，我们还是为本系列文章的下一篇保留一些好东西吧(剧透：又涉及到了flatMap)。

结论

今天就到这里了。

在第3部分中我们没做太多事情，仅仅就是把class换成了struct。我甚至没讲哪怕一点儿关于两者之间的区别(然而即使我最近特别忙，有段时间没在blog上发东西了，我还是不想你为新文章等待太久)。

但是我们最终丢弃掉NSURL!，将最后一匹小马拯救🎉。在我下一篇文章发布出来前，看一下Andy关于《和值类型交朋友》的超棒讨论，你还是有很多东西要去学的。

我承诺在发布第4部分之前不会让你等太久，第4部分又涉及到map和flatMap，但这一次是基于Optionals。

  1. 没错，上篇文章中你确实做了一些函数式编程…你自己可能甚至都没有意识到。

  2. NSURL!一直纠缠我到现在已经有段时间了，其实我就是太懒了，没去为ListItem类写一个正确的init方法。因为知道我迟早会把它弄掉，所以处理它之前我没想收拾那段代码样本。我们拯救最后一匹小马仅仅是时间问题。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 swift.gg。

avatar
文章
阅读
粉丝