昨天我们在用swift的枚举简化登录操作内容中大大的赞美了枚举。今天我们说的内容参考自Swift enums - the not so good parts，这位博主就发表不同意见了，他说，swift的枚举确实挺牛逼的，他本人也爱用，但是咱们可不能有了新欢就忘了旧爱呀。并流露出 “使用枚举来简化登录操作” 就是挺明显的忘旧爱。我们看看他是怎么看待这个事儿的。
我这里用了“参考”两个字，是因为我没有对原文进行逐句翻译工作，我按照自己的重新组织了内容，所以推荐大家阅读原文，毕竟是原滋原味的吗。另外如果发现我内容中不正确的地方，也烦请留言告诉我，八条8tiao会嗷嗷感激你的。
先实现个登录
enum LoginProvider {
case Facebook
case Email(LoginUser)
}
struct LoginUser {
let email: String
let password: String
func isValid() -> Bool {
return email != "" && password != ""
}
}
咱们先别贪多，就先弄两个登录选项，把流程跑通。下面我们就添加验证(isValid)和登录（login）方法。
enum LoginProvider {
func login() {
switch self {
case let .Email(user):
print("login with email: \(user)")
case .Facebook:
print("login with Facebook")
}
}
var isValid: Bool {
switch self {
case let .Email(user):
return user.isValid()
case .Facebook:
print("Facebook is invalid :P")
return false
}
}
}
妥了，大功告成，这代码帅呆了，属于完全不用测试可以直接上线那种。
如果不是很理解文中代码的意思，推荐看另外一个篇文章用swift的枚举简化登录操作，那里有详细的描述，本文可以看做它的续集。
现在方案，架构，流程全通了，我们再费点体力增添点其他的登录选项吧，让用户为我们点赞是我们不懈的追求啊！新增Twitter，Google，Phone三种登录方式，让用户不点赞自己都感到羞愧。
enum LoginProvider {
case Facebook
case Email(LoginUser)
case Twitter
case Google
case Phone(String)
func login() {
switch self {
case let .Email(user):
print("login with email: \(user)")
case .Facebook:
print("login with Facebook")
case .Twitter:
print("login with Twitter")
case .Google:
print("login with Google")
case let .Phone(phone):
print("login with Phone: \(phone)")
}
}
var isValid: Bool {
switch self {
case let .Email(user):
return user.isValid()
case .Facebook:
print("Facebook is invalid :P")
return false
case .Twitter:
print("Twitter random ") //¯\_(ツ)_/¯
return arc4random_uniform(2) == 1
case .Google:
print("Google yes")
return true
case let .Phone(phone):
print("login with Phone: \(phone)")
return phone.isValid()
}
}
}
窝草~，发现没有，这个枚举的代码突然暴增啊。原因应该是这样的：每增加一种新的登录方式，我们就要新增两处代码
- login()方法中，新增对应的登录操作
- isValid()方法中，新增对应的验证代码。
重新准守开闭原则
也就是说我们每次新增一种登录方式，我们就得修改一次现有代码，这就破坏了我们的软件架构的一条重要基本原则：开闭原则
开闭原则说的是：软件应该对修改关闭而对新增开放，也就是说我在新增功能的时候应该通过新增代码的方式来实现，而不是通过修改老的代码来实现。
虽然原作者没有明说，但是我想他一定为我们这些只顾为枚举点赞的人摇头啊。他认为我们不能破换开闭原则，对于登录问题咱们应该这么干。
protocol LoginProvider {
func login()
var isValid: Bool { get }
}
先用协议定义一个登录的规范，然后每种方式定义自己的具体实现，就像下面这样。
//FacebookLoginProvider.swift
struct FacebookLoginProvider: LoginProvider {
func login() {
print("login with Facebook")
}
var isValid: Bool {
print("Facebook is invalid :P")
return false
}
}
//EmailLoginProvider.swift
struct EmailLoginProvider: LoginProvider {
var user: LoginUser
func login() {
print("login with email: \(user)")
}
var isValid: Bool {
return user.isValid()
}
}
大家看到这样的好处了么？每一种登录都是一个独立的struct而互不干涉，不像枚举方式生活在一个大屋子里面，乱糟糟的。这些struct只要准守一个共同协议就可以实现登录了。如果我们需要新增一中登录方式，我们就再新增一个struct
struct TwitterLoginProvider: LoginProvider {
func login() {
print("login with Twitter")
}
var isValid: Bool {
return arc4random_uniform(2) == 1
}
}
怎么样？完全准守了开闭原则吧，所以呀！作者说的没有错，你们这些程序员啊，就是有了新欢忘了旧爱呀！
总结
好了，希望这篇内容能够增加一点点你对enum，struct的思考。
