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

2020-09-18 本文已影响0人醉看红尘这场梦

我们了解了在Swift中使用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，现在，我们也终于可以如愿了。

这一节，我们最核心的一个思想，就是函数除了可以当作加工数据的过程之外，函数类型自身，还可以当作一种数据类型来使用，通过合理利用函数类型，我们可以把一些运行时才能完成的事情，抽象到编译期进行安全检查，进而提高代码的可靠性。但我们的方案还有值得改进的地方：

在makeDescriptor中，如果key返回的是optional，我们并没有处理这种情况；
先combine再调用sorted或多或少有点儿不自然，毕竟这也算是一个实现的细节，如果我们在写一个library，这显然是没必要暴露给使用者的；

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

从排序函数开始

合并多个排序条件

阶段性总结

猜你喜欢

热点阅读