Swift 4.1 新特性 (4) Codable的改进

在 Swift 4.0 的标准库中,引入了 Codable 接口,它实际上是 Encodable & Decodable 两个接口的复合接口。感谢编译器的加持,可以很方便地合成 init(from:Decoder) 以及 encode(to:Encoder) 这两个函数。Swift 4.1 为 JSONEncoder 和 JSONDecoder 分别引入了两个新的属性: keyEncodingStrategy 以及 keyDecodingStrategy,来详细了解一下用途。

1. 弥合下划线命名和驼峰命名

在日常使用过程中,我们经常会碰到强类型对象和 JSON 不同命名风格转换的问题,来看下面的例子。

let jsonStr = """
{
"age": 18,
"first_name": "Leon"
}
"""

struct Person : Codable {
  var age: Int
  var firstName: String
}

在这个例子中,JSON 字符串无法解码成 Person,同时 Person 的实例也无法编码成这个 JSON 字符串。原因就在于第二个属性的命名风格是不同的,前者使用了下划线命名法 (Snake Case),后者使用了驼峰命名法 (Camel Case)。为了解决这个问题,在Swift 4.0 中,我们需要在 Person 内部自定义一个 CodingKeys,如下:

enum CodingKeys : String, CodingKey {
    case age
    case firstName = "first_name"
}

这个内部枚举 CodingKeys 的 rawType 是 String,并且声明实现 CodingKey 接口。这时,编译器会使用它的信息合成 Codable 相关函数,包括 Person.CodingKeys 的完整实现,问题解决。而在Swift 4.1 中,解决这个问题有了个更方便的方法:不指定 CodingKeys,而是在编码的时候,把 JSONEncoder 的属性 keyEncodingStrategy 设置为 .convertToSnakeCase;在解码的时候,把 JSONDecoder 的属性 keyDecodingStrategy 设置成 .convertFromSnakeCase。代码如下:

// 编码
let leon = Person(age: 18, firstName: "Leon")
let encoder = JSONEncoder()
encoder.keyEncodingStrategy = .convertToSnakeCase
let resultData = try? encoder.encode(leon)

// 解码
let data = jsonStr.data(using: .utf8)!
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let person = try? decoder.decode(Person.self, from: data)

2. 自定义键策略

大家一定想到了,上面这个例子只解决了最典型的一种 Key 风格不匹配的情况。有很多其它情况需要覆盖,比如:首字母大写的帕斯卡命名法了解一下?

let jsonStr = """
{
"Age": 18,
"FirstName": "Leon"
}
"""

实际上,我们需要更通用的方法,来解决 JSON 解码和编码的键策略问题。它就是 keyEncodingStrategy 和 keyDecodingStrategy 的另一个枚举项 .custom(([CodingKey]) -> CodingKey>),我们看到它接受一个 CodingKey 数组到 CodingKey 的函数作为关联值。

那么 CodingKey 到底是什么呢?官方这样定义:一种被当做键 (Key) 用于编码和解码的类型。它是个 protocol,定义了以下四个方法,简写如下:

protocol CodingKey {
  var stringValue: String { get }
  init?(stringValue: String)

  var intValue: Int? { get }
  init?(intValue: Int)
}

我们看到:

  1. 可划分为 stringValue 和 intValue 两对,分别代表以 String 为键和以 Int 为键的两种情况。
  2. 在每一种对方法中,定义对 String / Int 的双向转换。
  3. 初始化函数是 failable 的。
  4. stringValue 不是 Optional 的,intValue 是 Optional 的。

回到需要解决的问题,我们需要传入的这个 ([CodingKey]) -> CodingKey> 函数,正是利用了 CodingKey 可以双向转换的特性,将一个 CodingKey 转换成另一种 CodingKey,所以实质上提供的是一个 map 函数。 看到这里,可能你有些疑惑,输入参数可是个数组,这里解释一下:之所以是数组是为了提供给你到当前编解码位置的完整路径,在大多数情况下,我们只需要取数组最后一个 CodingKey 即可。

结合之前的例子解决方案如下:默认情况在编码成 JSON 的时候,Encoder 会使用 Person.CodingKeys 进行编码,调用它的 stringValue,最终给出在实际 JSON 中当做键的字符串(驼峰命名风格的)。当使用 .custom 键编码策略的时候,就在上述过程中插入了一步:将 Person.CodingKeys 转变成了另一个 CodingKey(下面实现中的 SimpleCodingKey ),在负责转换的 map 函数中,将 stringValue 从 Person.CodingKeys 对象中取出,首字母变成大写,再用来构造 SimpleCodingKey,这时候实际用以 JSON 编码的 CodingKey 被替换成 SimpleCodingKey了(帕斯卡命名风格)。实现代码如下:

struct SimpleCodingKey : CodingKey {
    var stringValue: String
    var intValue: Int?
    
    init(stringValue: String) {
        self.stringValue = stringValue
    }
    
    init(intValue: Int) {
        self.stringValue = "\(intValue)"
        self.intValue = intValue
    }
}

extension JSONEncoder.KeyEncodingStrategy {
    static var convertToPascalCase: JSONEncoder.KeyEncodingStrategy {
        return .custom { codingKeys in
            var str = codingKeys.last!.stringValue
            guard let firstChar = str.first else {
                return SimpleCodingKey(stringValue: str)
            }
            let startIdx = str.startIndex
            str.replaceSubrange(startIdx...startIdx,
                                with: String(firstChar).uppercased())
            return SimpleCodingKey(stringValue: str)
        }
    }
}

let leon = Person(age: 18, firstName: "Leon")
let encoder = JSONEncoder()
encoder.keyEncodingStrategy = .convertToPascalCase
let resultData = try? encoder.encode(leon)

这里有两处实现细节要注意一下:

  1. SimpleCodingKey 的初始化方法不是 failable 的,但根据实现的要求,非 failable 的初始化方法被认定为实现了接口中的 failable 初始化方法
  2. extension 中使用了语法糖,添加的 convertToPascalCase 实际上是个 static var,但可以用类似于 enum 实例的语法来使用。

以上解决了编码部分,其实解码部分也是类似的,区别在于代码中的 uppercased 换成 lowercased。CodingKeys 的转换过程可以被描述为:_JSONKey 的对象需要转换成首字母小写的 SimpleCodingKey ,然后 SimpleCodingKey 再被拿去匹配 Person.CodingKeys,这个函数大家可以尝试自己实现一下。

3. 设计亮点

在了解了新特性的基础和高级用法之后,这里想简单提一下 Codable 的设计亮点,从设计者的角度学习和了解下。

  1. 基于接口的面向对象设计:从微观来看 CodingKey 接口的稳定设计抽象,使得 Swift 4.1 中加入 .custom CodingKey 的转换成为可能。从宏观来看 Encoder 和 Decoder,乃至 Codable 都是基于接口的面向对象设计,这使得整套设计是独立于具体格式的,标准库中内置了 JSON 和 PropertyList 两种编解码器,而你可以通过实现自己的 Encoder 和 Decoder,支持新的格式。
  2. 关联值枚举作为配置属性:KeyEncodingStrategy 和 KeyDecodingStrategy 中的.custom(([CodingKey]) -> CodingKey>),让策略以一种优雅的方式得以动态配置。类似的设计我们还可以从 dateEncodingStrategy 等地方看到。
  3. 泛型设计和元类型编程:我们在解码JSON的时候是这么写的:try? decoder.decode(Person.self, from: data)这里传入 Person.self 其实就涉及到了元类型编程了。这个函数是原型是:func decode(_ type: T.Type, from data: Data) throws -> T where T : Decodable,如果要展开说,就是另一个话题了。我们可以在了解元类型设计的时候,想到这个范本。

小结

Codable在 Swift 4.0 的引入以及在 Swift 4.1 中的加强给 Swift 强类型持久化方案提供了新的技术选型,而且是第一梯队的。除了上述所提到的设计亮点,它还有亲儿子独有的编译器合成特性,以及存在于标准库的待遇,而后者的意义对于许多框架和库的作者来说,足以使之成为首选方案。

在本文中,我们讨论了:

  • 使用新的配置属性弥合下划线命名和驼峰命名
  • CodingKey 设计和自定义 CodingKey 转换
  • 简单描述了 Codable 的设计亮点
  • 我们应该将 Codable 纳入 Swift 持久化方案的优先技术选型
欢迎关注公众号

Swift 4.1 新特性系列文章

Swift 4.1 新特性 (1) Conditional Conformance
Swift 4.1 新特性 (2) Sequence.compactMap
Swift 4.1 新特性 (3) 合成 Equatable 和 Hashable
Swift 4.1 新特性 (4) Codable的改进

你可能感兴趣的:(Swift 4.1 新特性 (4) Codable的改进)