登录。。。基本所有APP都少不了，开始写APP，可能首先就是从登录开始
我也一样，我手上有一个封装了所有账户体系相关接口的SDK，运行良好但也遇到一些烦心事，就拿登录来说说吧。
首先有如下相关封装，很常见，也无需太多解释：
import Foundation
public typealias Response = (_ json: String?, _ error: Error?) -> Void
// 账户体系管理器
public class AccountMgr: NSObject {
private override init() {}
public static let shared = AccountMgr()
}
public extension AccountMgr {
/// 登录
/// - Parameters:
/// - accountType: 账户类型 see `AccountType`
/// - password: 密码
/// - res: 请求结果
func login(by accountType: AccountType, password: String, res: Response?) {
var params = [String: Any]()
switch accountType {
case let .email(email):
params["type"] = "email"
params["email"] = email
case let .mobile(mobile, mobileArea):
params["type"] = "mobile"
params["mobile"] = mobile
params["mobileArea"] = mobileArea
}
params["password"] = password
//网络请求，并回调
//request(type: .post, api: .login, params: params, res: res)
}
}
/// 账号类型
public enum AccountType {
/// 手机号
/// - mobile: 手机号
/// - mobileArea: 国家区号（中国 86）
case mobile(_ phoneNumber: String, mobileArea: String = "86")
/// 邮箱
case email(_ email: String)
}
使用也很方便：
// 分开使用
AccountMgr.shared.login(by: .email(""), password: "", res: nil)
AccountMgr.shared.login(by: .mobile("", mobileArea: ""), password: "", res: nil)
// 合并使用
var loginType: AccountType
if inputEmail {
loginType = .email("test@weixian.com")
} else {
loginType = .mobile("18000000000", mobileArea: "86")
}
AccountMgr.shared.login(by: loginType, password: "xxxxx", res: nil)
无论是邮箱，手机号登录分开逻辑登录，还是统一的登录管理器登录都能胜任，并且只有两种登录，分开写也不会多很多代码。
有一天，这个SDK需要在OC项目中使用
感觉没爱了，懒得想太多，直接废弃了Swift 枚举的便利性，写成了两个方法：
public class AccountMgr: NSObject {
private override init() {}
@objc(shareInstance)
public static let shared = AccountMgr()
}
@objc func loginBy(email: String, password: String, res: Response?)
@objc func loginBy(mobile: String, mobilArea: String, password: String, res: Response?)
之所以写成loginBy(email:)而不是login(by email:)，主要是为了swift 转 OC 后使用的时候能直接看懂，也不需要去查看定义，看如下截图就能明白了：
第一个方法不看定义，应该没办法了解参数应该填什么了。
就这样，我的SDK又运行了一段时间,看起来也没什么大问题，无非是手机登录和邮箱登录一定要分开调用罢了
又有一天，这个登录方法要增加用户账号登录
依样画葫芦，我又增加了一个接口~~~，只是这样，那故事就结束了。
可惜，我还有第三方绑定接口，即微信登录后绑定手机，邮箱，或账号、、、、这里又三个接口，还有查询账号信息又三个，还有。。。又三个。。。，还有。。。又三个。。。
这个时候我又开始怀念第一版的接口了，其实这很容易解决，只要一个整型枚举，然后把多出来的参数设置为可选，虽然使用的时候会有点奇怪，但是很好的解决了问题。并且最终我也是这么做的，可我还是想在Swift中能够更好的使用Swfit特性，写出更简洁的代码。。所以我写了两套接口。。。。，一套OC使用，一套Swfit使用，因为我总觉得在不久的将来，我就不需要支持OC了：
首先增加了一个OC的类型枚举：
@objc public enum AccountType_OC: Int {
case mobile
case email
case userId
}
然后增加了一个只有OC可用的方法：
@available(swift 10.0)
@objc func loginBy(accountType: AccountType_OC, account: String, password: String, mobileArea: String?, res: Response?) {
let type = getSwiftAccountType(accountType: accountType, account: account, mobileArea: mobileArea)
login(by: type, password: password, res: res)
}
private func getSwiftAccountType(accountType: AccountType_OC, account: String, mobileArea: String?) -> AccountType {
var type: AccountType
switch accountType {
case .mobile:
guard let mobileArea = mobileArea else { fatalError("need mobile area") }
type = .mobile(account, mobileArea: mobileArea)
case .email:
type = .email(account)
case .userId:
type = .userId(account)
}
return type
}
OC中没办法给参数赋默认值，即类似mobileArea: String = "86" 这种，完全没有用。。。
私有类型转换的方法的封装，使得所有其他方法可以快速转换，关于@available(swift 10.0) 意思就是说只有Swift 版本10.0只后才可以使用。。即变相达到了，在Swift 代码中不会出现这个方法，只有下面方法可以使用：
func login(by accountType: AccountType, password: String, res: Response?)
基本就是这样了，看起来很麻烦，也确实挺麻烦，其实完全可以只保留OC使用的方法，这完全归于我的代码洁癖，以及我自己在使用Swift和对于日后去掉OC支持时我可以快乐的删代码的白日幻想。
当然，如果你只是在自己的混编APP内部封装一些接口，那一套接口应该是比较好的，如果你的是SDK,同时你也不是很怕麻烦，像我这样写也许会有一些意外的收获。
