是否有技术原因使用 Swift 的无壳枚举而不是真实案例？

Question

作为 Swift 的新手，这就是我发现的：

enum HttpMethod {
  static let post = "POST"
  static let get = "GET"
}

// can assign to string property.
request.httpMethod = HttpMethod.post // --> "POST"

阅读本文后，使用无壳enum而不是无壳的原因对struct我来说很有意义，但这不是我在这里感兴趣的事情。

拥有强大的 C# 背景，这就是我实现它的方式：

enum HttpMethod: String {
  case post = "POST"
  case get = "GET"
}

// I'd even consider this alternatively:
enum HttpMethod: String {
  case post
  case get
}

// Must retrieve string value
request.httpMethod = HttpMethod.post.rawValue // --> "POST" or "post"

第二个版本需要使用，rawValue但它将枚举视为真正的枚举。来自 C# 我习惯于使用.ToString()枚举值。

这一切只是归结为个人喜好和 Swift 使用无壳枚举而不是实际案例 + rawValue 的惯例，还是有另一个（技术）原因更喜欢第一个版本而不是第二个版本？

Answer 1

带案例的枚举

最好在以下场景中创建带有案例的枚举：

• 它是互斥的
• 您在编译时知道的有限值集
• 您是定义它的人（如果在框架中定义了枚举，您将无法扩展它以添加更多案例）

枚举的优点是：

• 由于这些值是一个有限集，您可以编写详尽的 switch 语句
• 更干净的代码

静态值：

当在框架中定义了struct/class并且您想要扩展它以添加更多值时。

的，其中该方法被用于实施例是Notification.Name在Foundation

笔记：

• swift 中的枚举非常强大
• 枚举可以有关联的值
• 枚举可以有其他功能。（如果你定义了 start、inProgress、finished 等状态，你可以定义一个名为 next 的函数，它可以返回下一个状态。start.next()
• 如果您处于值不相互排斥的场景中，例如它可以是值的组合，那么请改用 OptionSet

结论

• 这一切都取决于你的意图

• 如果您事先知道这些值并且它们不会改变，那么创建一个 enum

• 如果这是不可能的，那就创造static价值。

• 如果您正在创建静态值，那么您就是在妥协，因此您不必在 an 中使用它enum，您可以将其定义为 astruct以便更清晰地表达意图。

• 到目前为止，有一个关于可扩展枚举的快速提案