使用func和closure加工数据(二)

使用func和closure加工数据(二)

[TOC]

OC中水土不服的运行时特性

如果你有过Objective-C的开发经验，一定会对它提供的各种运行时特性印象深刻。基于这些特性提供的功能更是灵活强大，可以帮助我们处理一些复杂的任务。但这一切，都是有代价的。没错，它们大多用起来都不直观，如果你不去刨一下文档，总不那么容易理解相关API的正确用法。

并且，既然这些特性是基于运行时的，因此，编译器仅可以对它们执行非常有限的检查。一旦你稍有疏忽，就得承担App闪退的严重后果。

用OC运行时特性进行排序

我们来看个和搜索有关的例子。首先，定义一个表示视频信息的类：

final class Episode: NSObject {
    var title: String
    var type: String
    var length: Int

    override var description: String {
        return title + "\t" + type + "\t" + String(length)
    }

    init(title: String, type: String, length: Int) {
        self.title = title
        self.type = type
        self.length = length
    }  
}

其实在Swift里，这类内容定义成Struct更为合适，但为了演示OC的运行时特性，我们把它定义成了一个派生自NSObject的类。并且，通过关键字final限制了它不能继续被继承。
Episode有三个属性，分别表示视频的标题、类型和长度。然后，我们重载了description属性，以便后面通过print直接打印Episode对象。

这一切很简单，然后，我们定义一些数据：

let episodes = [
    Episode(title: "title 1", type: "Free", length: 520),
    Episode(title: "title 4", type: "Paid", length: 500),
    Episode(title: "title 2", type: "Free", length: 330),
    Episode(title: "title 5", type: "Paid", length: 260),
    Episode(title: "title 3", type: "Free", length: 240),
    Episode(title: "title 6", type: "Paid", length: 390),
]

接下来，我们要先按type排序，并在排序后的结果里，继续按照length排序，该怎么办呢？Apple在开发者文档里介绍了一种叫做NSSortDescriptor的用法，这就是一个典型的功能强大，但是又必须要看文档才能掌握的技能。

为了排序type ,首先，我们定义一个typeDescriptor:

let typeDescriptor = NSSortDescriptor(
    key: #keyPath(Episode.type),
    ascending: true,
    selector: #selector(NSString.localizedCompare(_:))
)

其中：

  • key：表示要排序的属性
  • ascending：表示是否按升序排列
  • selector：表示要进行比较的方法
    其次，定义一个Array<NSDescriptor>:
let descriptors = [ typeDescriptor ]

最后，把episodes转型成NSArray,调用sortedArray(using:)方法，把descriptors传递给它：

let sortedEpisodes = (episodes as NSArray).sortedArray(using: descriptors)

这样，就完成排序了，但我们会得到一个Array<Any>的结果，为了查看它的内容，我们得这样：

sortedEpisodes.forEach { print( $0 as! Episode )}

然后我们就可以再控制台看到下面的结果了：

title 1 Free    520
title 2 Free    330
title 3 Free    240
title 4 Paid    500
title 5 Paid    260
title 6 Paid    390

此时，我们就完成了按Type进行排序，接下来，我们还要在这个排序结果里，把Free和Paid的视频按时间排序。理解了上面的套路之后，就很简单了，我们继续定义一个lengthDescriptor:

let lengthDescriptor = NSSortDescriptor(
    key: #keyPath(Episode.length),
    ascending: true
)

这次，我们使用系统默认的整数比较操作符就好了，可以不明确指定要使用的selector。定义好之后，直接把它添加到之前创建的descriptors数组里：

let descriptors = [ typeDescriptor, lengthDescriptor ]

这样重新执行一次，sortedArray(using:)方法就会返回这样的结果：

title 3 Free    240
title 2 Free    330
title 1 Free    520
title 5 Paid    260
title 6 Paid    390
title 4 Paid    500

看到了吧，现在，每一类视频里，就是按照时长进行排序的了，这就是NSSortDescriptor的用法。当你理解了这个过程之后，就能体会到它的功能强大，我们可以在descriptors数组中，包含任意多个不同的NSSortDescriptor对象，来实现复杂的搜索功能。但是，如果你不看文档，Hmmmm...，估计你也很难理解它的使用方法。

除了不怎么好学之外，上面的方法在Swift里还有个先天不足，就是我们使用了OC的两个运行时特性：一个是Key-Value coding，用来读取属性中的值，一个是selector，用来表示排序时使用的算法。编译器对这些当然一无所知，只要语法上正确，就会开绿灯。但是，显然，调试运行时错误要比编译错误麻烦的多。

那Swift的方式呢？

显然，尽管NSSortDescriptor的思想并不难掌握，但把它用在Swift里，还是显得有点水土不服，这主要表现在：

  • 首先，从定义之处，就限制了我们必须使用class，必须从NSObject派生。但显然，这样的信息在Swift更适合定义成Struct
  • 其次，我们要在使用API的时候，把Arraybridge 到 NSArray，从NSArray再bridge回来的时候，类型变成了Any,我们还要手工找回类型信息
  • 最后，KVC和selector都没有利用编译器提供足够充分的类型检查
    所以，对于Swift原生类型来说，NSSortDescriptor并不是复杂排序规则的最佳解决方案。那就究竟该怎么办呢？你可能会想，Array不是有一个接受函数参数的sorted方法么：
episodes.sorted {
    // Complex sorting code here
}

但这并不是一个好主意，相比之前NSSortDescriptor的方式，不仅我们无法有效表达要排序的规则，而且，把这些规则统统塞进一个排序函数中也并不利于维护。想象一下，如果现在我们又要对title和length排序了该怎么办呢？

从排序函数开始

为了模拟NSSortDescriptor的实现，我们得先从它的排序函数做起。简单来说，这就是一个接受两个同类型的参数，并且返回Bool的函数，我们可以用一个typealias来表示：

typealias SortDescriptor<T> = (T,T) -> Bool

于是，两个比较String的descriptor可以写成：

let stringDescriptor: SortDescriptor<String> = {
    $0.localizedCompare($1) == .orderedAscending
}

但有时，我们实际上要比较的内容，不是T,而是T的某个属性，例如，我们上面提到的Episode的长度：

let lengthDescriptor: SortDescriptor<Episode> = {
    $0.length < $1.length
}

观察这两个例子，如果我们要抽象SortDescriptor的创建过程，要解决两个问题：

  • 首先，对于要排序的值，不能简单的认为就是SortDescriptor泛型参数的对象，它还有可能是这个对象的某个属性。因此，我们应该用一个函数来封装获取排序属性这个过程；
  • 其次，对于排序的动作，有可能是localizedCompare这样的方法，也有可能是系统默认的<操作符，因此，我们同样要用一个函数来抽象这个比较的过程；
    理解了这两点之后，我们就可以试着为SortDescriptor，创建一个工厂函数了：
func makeDescriptor<Key, Value>(
    key: @escaping (key) -> Value,
    _ isAscending: @escaping (Value, Value) -> Bool) -> SortDescriptor <Key> {
    return { isAscending(key($0), key($1)) }
}

在上面的代码里，我们使用@escaping修饰了用于获取Value以及排序的函数参数，这是因为在我们返回的函数里，使用了key以及isAscending，这两个函数都逃离了makeDescriptor作用域，而Swift 3里，作为参数的函数类型默认是不能逃离的，因此我们需要明确告知编译器这种情况。

然后，我们就可以这样来定义用于按type和length排序的descriptor：

let lengthDescriptor: SortDescriptor<Episode> =
    makeDescriptor(key: { $0.length }, <)

let typeDescriptor: SortDescriptor<Episode> =
    makeDescriptor(key: { $0.type }, {
        $0.localizedCompare($1) == .orderedAscending
    })

在上面这段代码里，相比NSSortDescriptor的版本，Swift的实现有了一点改进。我们使用了{ $0.length }和{ $0.type }`这样的形式指定了要比较的属性。这样，当指定的属性和后面用于排序的方法使用的参数类型不一致的时候，编译器就会报错，避免了在运行时因为类型问题带来的错误。

有了这些descriptors，就离NSSortDescriptor的替代方案更进一步了。我们先试一下其中一个descriptor：

episodes.sorted(by: typeDescriptor)
    .forEach { print($0) }

就可以在控制台看到已经按type进行排序了：

title 1 Free    520
title 2 Free    330
title 3 Free    240
title 4 Paid    500
title 5 Paid    260
title 6 Paid    390

合并多个排序条件

接下来，我们要继续模拟通过一个数组来定义多个排序条件的功能。怎么做呢？我们有两种选择：

  • 通过extension Sequence，添加一个接受[SortDescriptor<T>]为参数的sorted(by:)方法；
  • 定义一个可以把[SortDescriptor<T>]合并为一个SortDescriptor<T>的方法。这样，就可以先合并，再调用sorted(by:)进行排序；
    哪种方法更好呢？为了尽可能使用统一的方式使用Swift集合类型，我们还是决定采用第二种方式。

那么，如何合并多个descriptors呢？核心思想有三条，在合并[SortDescriptor]的过程中：

  • 如果某个descriptor可以比较出大小，那么后面的所有descriptor就都不再比较了；
  • 只有某个descriptor的比较结果为相等时，才继续用后一个descriptor进行比较；
  • 如果所有的descriptor的比较结果都相等，则返回false；
func combine<T>(rules: [SortDescriptor<T>]) -> SortDescriptor<T> {
    return { l, r in
        for rule in rules {
            if rule(l, r) {
                return true
            }
            
            if rule(r, l) {
                return false
            }
        }
        
        return false
    }
}

在上面的代码里，只有一个技巧，就是我们使用了rule(l, r)和rule(r, l)同时为false的情况，模拟了r和l相等的情况。其余，就是我们之前提到的三点核心思想的实现，很简单。有了combine方法，我们就可以把之前的typeDescriptor和lengthDescriptor合并起来了：

let mixDescriptor = combine(rules: 
    [typeDescriptor, lengthDescriptor])

然后，我们可以使用合并后的结果，对episodes进行排序：

episodes.sorted(by: mixDescriptor)
    .forEach { print($0) }

这样，我们就可以得到和之前NSSortDescriptor同样的结果了：

title 3 Free    240
title 2 Free    330
title 1 Free    520
title 5 Paid    260
title 6 Paid    390
title 4 Paid    500

阶段性总结

回顾下我们的Swift实现，整体过程是这样的：

首先，在Swift里，我们使用函数类型替代了OC中的NSSortDescriptor类，表示了一个排序规则：

typealias SortDescriptor<T> = (T, T) -> Bool

其次，我们使用函数类型替代了OC中的Key-Value coding和selector，来获取要排序的属性，和执行排序的selector：

func makeDescriptor<Key, Value>(
    key: @escaping (Key) -> Value,
    _ isAscending: @escaping (Value, Value) -> Bool
) -> SortDescriptor<Key> {

        return { isAscending(key($0), key($1)) }
}

第三，我们用类似的方式，创建了一个[SortDescriptor<T>]。不同的是，我们没有直接把这个数组传递给排序方法，而是把数组中所有的descriptor合并成了一个排序逻辑之后，再进行排序：

// 1. Create descriptors
let lengthDescriptor: SortDescriptor<Episode> =
    makeDescriptor(key: { $0.length }, >)

let typeDescriptor: SortDescriptor<Episode> =
    makeDescriptor(key: { $0.type }, {
        $0.localizedCompare($1) == .orderedAscending
    })

// 2. Combine descriptor array
let mixDescriptor = combine(rules: 
    [typeDescriptor, lengthDescriptor])

// 3. Sort
episodes.sorted(by: mixDescriptor)

这样，我们不仅保留了NSSortDescriptor的编程思想，也充分利用了Swift是一门强类型语言的特性，尽可能在编译期保障代码安全。另外，通过这种方案，我们还去掉了对要排序类型的限制，现在，它可以是任意一个Swift的原生类型：

struct Episode: CustomStringConvertible {
    // The same as before
}

我们之前说过，类似Episode这样的类型，更适合用一个struct，现在，我们也终于可以如愿了。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,324评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,303评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,192评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,555评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,569评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,566评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,927评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,583评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,827评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,365评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,941评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2赞 342

推荐阅读更多精彩内容

  • 读硅谷来信有感
    #文明之光#： 自从订阅了吴军老师的硅谷来信，刚开始我的睡眠时间变晚了，因为硅谷来信是每天零点更新。每天深夜阅读更...
    随思录阅读 318评论 0赞 0
  • 老朋友
    可能怨相识太早 岁月太长 好久不见啊 老朋友 你可过得静好 曾无话不谈 呼吸一片天 吃同样的苦 遭受同样的埋怨 而...
    写手沈然阅读 368评论 0赞 0