swift的枚举为何让这位外国程序员感到沮丧？
这两天我经常在网上搜罗关于枚举部分的内容，发现有几篇博文内容是有共性的，这让我感到挺有趣的。首先这几篇内容都在抱怨枚举存在的问题，第二博主们谁也没有找到最佳解决方案。我把这些内容总结一下，如果碰巧你看到，并且有好的方案，一定记得要帮助那几位外国程序员才行。博文的地址我列在内容的末尾。
有什么不开心的事情？说出来让大家开心开心！
一位歪果程序员，胖胖的（我想像他是胖胖的），正沮丧的使用枚举来描述一种细菌的状态。
enum Statement {
case Import(keyword: Token, packageName: Token)
case Assignment(binding: Token, value: Expression)
}
接着他需要定义一个parseImport()方法，用来解析具体的Import状态，这时令他困扰的第一件事情发生了。parseImport无法这样定义返回值。
func parseImport() throws -> Statement.Import { ... }
swift只允许我们这样返回枚举
func parseImport() throws -> Statement { ... }
也就是说：我们是不能够把一个具体的case内容作为方法的返回值，只能使用枚举的类型作为返回值。
胖胖的程序员提出的他的质疑：associated value枚举到底比struct强在了哪里？如果他使用struct的话完全可以实现一个理想中的parseImport（）
protocol Statement {}
struct Import : Statement {
let keyword: Token
let packageName: Token
}
struct Assignment : Statement {
let binding: Token
let value: Expression
}
func parseImport() throws -> Import { ... }
这样做有几点好处：
- 使用协议可以让struct们获得统一的类型 Statement,就像枚举类型那样。
- 每个struct都有自己独自的类型，例如 Import、Assignment
- parseImport方法可以返回Import了（该点与第二点相同）
这位歪果程序员认为，在这种情况下，枚举唯一的优势就是：简洁，不知道你是如何看待这个问题，如果你有更深入的想法，请千万不要保留，留言给我吧。
又遇到不开心的事情了！
没过几天，这位程序员又遇到烦恼了，他认为swift枚举存在一个比较尖锐的问题是：关联值类型与实际类型之间的耦合。就像这样的代码，case Import(keyword: Token, packageName: Token)，所以他使用了一种缓解症状的办法.
typealias ImportStatement = (keyword: Token, packageName: Token)
typealias AssignmentStatement = (binding: Token, value: Expression)
enum Statement {
case Import(ImportStatement)
case Assignment(AssignmentStatement)
}
虽然这样就可以让解析的方法返回 ImportStatement 但这位程序员认为这样处理存在几个问题：
- 将类似(keyword: Token, packageName: Token)的内容转化为Statement过程很乏味
- 类型定义的位置不理想
- 只有代码是自己的，才能使用这种缓解的方式
如果代码是第三方的，例如，官方文档中的：
enum Barcode {
case UPCA(Int, Int, Int, Int)
case QRCode(String)
}
如果我们实现一个解析UPCA的方法，我们在返回值上面可能只有两种选择
parseUPCA() -> (Int, Int, Int, Int)
或者
parseUPCA() -> Barcode
- 对于第一种选择，一旦UPCA的定义数据发生变化，那么我们只能update所有涉及到的代码，这就是由于枚举关联类型与实际类型之间的耦合造成的数据过度暴露。
- 对于第二种方式，返回一个不明确的Barcode，然后在解析其数据，这不就又回到本文的第一个问题了么？
总结
我个人认为，文中所抱怨的问题，恰恰是因为枚举的associated value特性太棒了，所以吸引着程序员们在更广阔的场景中尝试使用枚举而引出的。我想随着swift语言的进一步的完善以及广大极客程序员们对最佳实践的不断探索，会让编程生活越来越精彩。
[ENUMS WITH ASSOCIATED DATA VS. STRUCTS](ENUMS WITH ASSOCIATED DATA VS. STRUCTS)
