在 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)
}

我们看到：

可划分为 stringValue 和 intValue 两对，分别代表以 String 为键和以 Int 为键的两种情况。
在每一种对方法中，定义对 String / Int 的双向转换。
初始化函数是 failable 的。
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)

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

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

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

3. 设计亮点

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

基于接口的面向对象设计：从微观来看 CodingKey 接口的稳定设计抽象，使得 Swift 4.1 中加入 .custom CodingKey 的转换成为可能。从宏观来看 Encoder 和 Decoder，乃至 Codable 都是基于接口的面向对象设计，这使得整套设计是独立于具体格式的，标准库中内置了 JSON 和 PropertyList 两种编解码器，而你可以通过实现自己的 Encoder 和 Decoder，支持新的格式。
关联值枚举作为配置属性：KeyEncodingStrategy 和 KeyDecodingStrategy 中的.custom(([CodingKey]) -> CodingKey>)，让策略以一种优雅的方式得以动态配置。类似的设计我们还可以从 dateEncodingStrategy 等地方看到。
泛型设计和元类型编程：我们在解码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的改进

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

2. 自定义键策略

3. 设计亮点

小结

Swift 4.1 新特性系列文章

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