在swift 4.0之后，官方提供了Codable来解析json为对应的Model，这比一些第三方框架简单优雅了许多，并且由于它是官方的，稳定性也有了很好的保障。
具体如何使用Codable来映射解析json并不是本文的重点，相信大家也都知道如何使用，本文主要讨论在解析枚举数据的时候遇到的问题，特别是可变枚举的情况。
常规enum
对于后端接口数据中有一些确定值范围的字段，比如性别这种，我们会使用枚举来解析这个字段。假如我们有如下这样的一个json数据，下文增加修改字段都是在该json的基础上进行的：
{
"name": "rocky",
"sex": "male"
}
我们和后端约定sex字段只能传递字符串male、female（当然，为了减少数据量，也会使用Int类型来表示对应的值），因此我们可以很容易的写出来对应的Person模型：
struct Person: Codable {
let name: String
let sex: Sex
enum Sex: String, Codable {
case male
case female
}
}
借助于JSONDecoder我们可以将json转化为对应的Person：
let person_json_data = JSONSerialization.data(withJSONObject: person_json, options: [.fragmentsAllowed])
let person = JSONDecoder().decode(Person.self, from: person_json_data)
但是在这个过程中，如果后端增加了一个sex字段的值：unknown，而且我们解析json的代码已经发版上线了，只要后端修改过后的接口一上线，就会解析失败。
除了后端对该值做版本控制之外，我们别无他法，虽然版本控制修补丁还可以，如果涉及到大面积的字段有变动，那就会割裂后端同学的代码逻辑。
如果一开始不使用枚举，而是直接使用String、Int来保存数据就不会有这样的问题了，既然我们这里讨论的是Codable下对enum的解析，那么这种case就不用考虑了。
使用OptionSet
上面的情况一般的发生主要在于业务变动，业务变动是无法预期的，但是我们可以使用OptionSet来提前预防这种情况。
OptionSet一般用来可以组合的枚举，通过或、与操作来达到对枚举的组合，比如UIKit中设置圆角的UIRectCorner就是他的一个应用：
struct UIRectCorner : OptionSet {
static var topLeft: UIRectCorner { get }
static var topRight: UIRectCorner { get }
static var bottomLeft: UIRectCorner { get }
static var bottomRight: UIRectCorner { get }
static var allCorners: UIRectCorner { get }
}
虽然看起来不是枚举，但是却可以达到枚举的效果，我们可以使用OptionSet来实现一个具有兼容性的枚举。
假如现在json中新增一个level的字段，这个字段我们使用Int类存储：
{
...
"level": 2,
...
}
对应的，Person中也需要新增一个Level的struct来解析这个字段：
struct Person: Codable {
...
let level: Level
struct Level: Codable, OptionSet {
typealias RawValue = Int
var rawValue: Int
init(rawValue: Int) {
self.rawValue = rawValue
}
static let low = Level(rawValue: 1 << 0) // 1
static let middle = Level(rawValue: 2 << 0) // 2
static let high = Level(rawValue: 3 << 0) // 3
}
}
这个时候，通过JSONDecoder我们解析得到的level为middle。
如果接口中新增了level相关的字段，比如：higher，值为4，使用以前的代码解析出来的level.rawValue就为4，而不是已经设置好的静态对象，最主要的是不会解析失败。
使用OptionSet之后，依然可以使用if-else、switch来判断具体的case，以switch为例：
switch person.level {
case .low:
print("level low \(person.level.rawValue)")
case .middle:
print("level middle \(person.level.rawValue)")
case .high:
print("level high \(person.level.rawValue)")
default:
print("level unknow \(person.level.rawValue)")
}
既兼顾了enum的特性又具备了可拓展的特点。
问题
虽然使用OptionSet之后我们的数据解析代码逻辑更健壮了，同时也会带来一些问题。
首先就是代码量增加了很多。针对这一点，我认为是值得的。特别是业务变动频繁带来的线上hot-fix等高成本的操作，多写这一部分代码显得没有那么重，另外可以在业务稳定之后，将struct替换为enum即可，几乎是无缝切换。
另外一个问题就是switch-case这样的判断逻辑上。我们知道enum中如果每个case都进行了区分，再新增一个case，编译器就会直接报错，提示我们有新增的case，记得在switch中进行区分。
而使用OptionSet之后，新增一个case，编译器并不会为我们进行提示，这就需要我们按照业务来主动添加了，这也无可厚非，毕竟有新业务变动了，肯定是要涉及到的地方都要修改了。
使用OptionSet实现enum的逻辑所带来的问题目前看来都是可以接受的，OptionSet也只是一种用于预防Codable解析失败的方式，具体业务中最好还是使用enum来实现枚举功能。
当然，如果业务变动很频繁，还是推荐使用OptionSet来提升代码的健壮性的。
