最近剛換工作见转，在遷移 Swift 4.0，其實(shí)我感覺 Swift 3.0 的時(shí)候遷移工作更容易一點(diǎn)，因?yàn)樗袔於己芊e極地升級(jí)版本，而現(xiàn)在反而都在做 Swift 3.2 的兼容方案算行，每個(gè)庫的兼容狀況不同讓遷移工作變得更難。
但今天想說的是另一個(gè)問題苫耸，Codable 的遷移州邢，我們項(xiàng)目里是用了 Moya + ObjectMapper 的方案，使用 Swift 的話鲸阔，大家使用的 JSON 解析方案應(yīng)該都一樣偷霉，都是定義協(xié)議迄委，模型遵守協(xié)議提供 JSON 解析的方法褐筛。
如果 JSON 格式標(biāo)準(zhǔn)，而且命名方式一致的話叙身，把 Mappable 全局替換成 Codable 就完成了 99% 的遷移工作了渔扎。但現(xiàn)實(shí)并不總是那么理想，那就只能保留 Mappable信轿，然后新的 Model 使用 Codable 來處理了晃痴，后面有空再來逐步替換。
理想的做法是不去動(dòng)網(wǎng)絡(luò)層的實(shí)現(xiàn)财忽，通過修改解析 JSON 的函數(shù)的實(shí)現(xiàn)來達(dá)到兼容倘核。先來看看 Moya-ObjectMapper 的實(shí)現(xiàn)：
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 的兼容其實(shí)也挺簡單的，重載這兩個(gè)方法就行了即彪，而一般項(xiàng)目里基本不怎么使用 context紧唱，所以可以這么定義：
// 這里偷懶沒有轉(zhuǎn)成 `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)
}
}
但我們后端的接口一般會(huì)在數(shù)據(jù)的外部再封裝一層，外部存放一些 status 或者 count 的信息隶校，于是我們就寫了一個(gè) 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 同時(shí)遵守 Codable 和 Mappable 會(huì)背離我們的初衷（雖然工作量不大）绰疤。
最理想的情況應(yīng)該是如果 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敛劝，直譯過來是“有條件地遵守”榨了，也就是說只要滿足了某個(gè)條件，就可以遵守協(xié)議攘蔽。這個(gè)功能還有各種各樣的用法龙屉，例如 Array 里的元素是 Equtable 的話，那 Array 也會(huì)遵守 Equtable，好好利用的話可以去掉很多抽象意義上相同的代碼转捕，Twitter 上甚至有人說使用這個(gè)功能就能將他項(xiàng)目里的代碼減少 20%作岖。
但目前這個(gè)功能暫時(shí)還沒有在 Swift 4.0 里實(shí)現(xiàn)，但前兩天已經(jīng)將對(duì)應(yīng)的 Pull Request 合并到了主分支里了五芝，很有可能在下個(gè)版本 Swift 4.1 里我們就能使用了??痘儡。
Note：
其實(shí)這種寫法還有另一個(gè)障礙，由于某些實(shí)現(xiàn)的原因枢步，目前 Codable 在 extension 里聲明的話沉删，是沒辦法自動(dòng)生成解析代碼的，不過也可以手動(dòng)實(shí)現(xiàn)醉途。Swift 團(tuán)隊(duì)已經(jīng)開了一個(gè) Pull Request 去實(shí)現(xiàn)這個(gè)功能了矾瑰，但由于暫時(shí)沒有好的實(shí)現(xiàn)方式，所以把 PR 關(guān)了隘擎，這個(gè)功能的實(shí)現(xiàn)可能還需要一段時(shí)間殴穴。
覺得文章還不錯(cuò)的話可以關(guān)注一下我的博客
