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 不同命名风格转换的问题，来看下面的例子。

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

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

2. 自定义键策略

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

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

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

我们看到：

可划分为 stringValue 和 intValue 两对，分别代表以 String 为键和以 Int 为键的两种情况。

在每一种对方法中，定义对 String / Int 的双向转换。

初始化函数是 failable 的。

stringValue 不是 Optional 的，intValue 是 Optional 的。

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

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

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

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 中的，让策略以一种优雅的方式得以动态配置。类似的设计我们还可以从 dateEncodingStrategy 等地方看到。

泛型设计和元类型编程：我们在解码JSON的时候是这么写的：这里传入 其实就涉及到了元类型编程了。这个函数是原型是：，如果要展开说，就是另一个话题了。我们可以在了解元类型设计的时候，想到这个范本。

小结

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

在本文中，我们讨论了：

使用新的配置属性弥合下划线命名和驼峰命名

CodingKey 设计和自定义 CodingKey 转换

简单描述了 Codable 的设计亮点

我们应该将 Codable 纳入 Swift 持久化方案的优先技术选型

Swift 4.1 新特性系列文章回顾