如何通过类型系统模拟OC的运行时特性?

本系列文章为个人学习笔记:禁止转载

从排序函数开始

为了模拟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,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容