swift枚举不太好的地方

昨天我们在用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的思考。