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

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

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

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

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

struct BaseResponse: 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 也兼容 CodableT 也必须遵守 Codable 才行,但让 T 同时遵守 CodableMappable 会背离我们的初衷(虽然工作量不大)。

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

struct BaseResponse {
    
    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 关了,这个功能的实现可能还需要一段时间。

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

你可能感兴趣的:(Codable 的迁移方案)