Codable 的迁移方案

最近刚换工作，在迁移 Swift 4.0，其实我感觉 Swift 3.0 的时候迁移工作更容易一点，因为所有库都很积极地升级版本，而现在反而都在做 Swift 3.2 的兼容方案，每个库的兼容状况不同让迁移工作变得更难。

但今天想说的是另一个问题，Codable 的迁移，我们项目里是用了 Moya + ObjectMapper 的方案，使用 Swift 的话，大家使用的 JSON 解析方案应该都一样，都是定义协议，模型遵守协议提供 JSON 解析的方法。

如果 JSON 格式标准，而且命名方式一致的话，把 Mappable 全局替换成 Codable 就完成了 99% 的迁移工作了。但现实并不总是那么理想，那就只能保留 Mappable，然后新的 Model 使用 Codable 来处理了，后面有空再来逐步替换。

理想的做法是不去动网络层的实现，通过修改解析 JSON 的函数的实现来达到兼容。先来看看 Moya-ObjectMapper 的实现：

extension Response {

    func mapObject<T: BaseMappable>(_ type: T.Type, context: MapContext? = nil) throws -> T {
        guard let object = Mapper<T>(context: context).map(JSONObject: try mapJSON()) else {
            throw MoyaError.jsonMapping(self)
        }
        return object
    }

    func mapArray<T: BaseMappable>(_ type: T.Type, context: MapContext? = nil) throws -> [T] {
        guard let array = try mapJSON() as? [[String : Any]] else {
            throw MoyaError.jsonMapping(self)
        }
        return Mapper<T>(context: context).mapArray(JSONArray: array)
    }
}

加入 Codable 的兼容其实也挺简单的，重载这两个方法就行了，而一般项目里基本不怎么使用 context，所以可以这么定义：

// 这里偷懒没有转成 `MoyaError` 再抛出
extension Response {
    
    func mapObject<T>(_ type: T.Type, using decoder: JSONDecoder = .init()) throws -> T where T: Decodable {
        return try decoder.decode(T.self, from: data)
    }
    
    func mapArray<T>(_ type: T.Type, using decoder: JSONDecoder = .init()) throws -> [T] where T: Decodable {
        return try decoder.decode(Array<T>.self, from: data)
    }
}

但我们后端的接口一般会在数据的外部再封装一层，外部存放一些 status 或者 count 的信息，于是我们就写了一个 BaseResponse 建模：

struct BaseResponse<T: Mappable>: Mappable {
    
    var statusCode: Int
    var message: String
    var totalCount: Int
    var result: T?
    
    required init?(map: Map) { }
    
    func mapping(map: Map) {
        statusCode <- map["statusCode"]
        message    <- map["message"]
        totalCount <- map["totalCount"]
        result     <- map["result"]
    }
}

如果想要兼容 Codable，那必然要让 BaseResponse 也兼容 Codable，T 也必须遵守 Codable 才行，但让 T 同时遵守 Codable 和 Mappable 会背离我们的初衷（虽然工作量不大）。

最理想的情况应该是如果 T 遵守 Codable 的话，那 BaseResponse 也能遵守 Codable。同样的，T 遵守 Mappable，BaseResponse 就遵守 Mappable：

struct BaseResponse<T> {
    
    var statusCode: Int
    var message: String
    var totalCount: Int
    var data: T?
}
 
extension BaseResponse: Mappable where T: Mappable {
   
    required init?(map: Map) { }
    
    func mapping(map: Map) {
        statusCode <- map["statusCode"]
        message    <- map["message"]
        totalCount <- map["totalCount"]
        data       <- map["data"]
    }
}

extension BaseResponse: Codable where T: Codable {}

这样的功能叫做 Conditional Conformance，直译过来是“有条件地遵守”，也就是说只要满足了某个条件，就可以遵守协议。这个功能还有各种各样的用法，例如 Array 里的元素是 Equtable 的话，那 Array 也会遵守 Equtable，好好利用的话可以去掉很多抽象意义上相同的代码，Twitter 上甚至有人说使用这个功能就能将他项目里的代码减少 20%。

但目前这个功能暂时还没有在 Swift 4.0 里实现，但前两天已经将对应的 Pull Request 合并到了主分支里了，很有可能在下个版本 Swift 4.1 里我们就能使用了✌️。

Note：

其实这种写法还有另一个障碍，由于某些实现的原因，目前 Codable 在 extension 里声明的话，是没办法自动生成解析代码的，不过也可以手动实现。Swift 团队已经开了一个 Pull Request 去实现这个功能了，但由于暂时没有好的实现方式，所以把 PR 关了，这个功能的实现可能还需要一段时间。

觉得文章还不错的话可以关注一下我的博客