最大的不同是Enumerations支持从某些nameString实例化它们。例如：
object Currency extends Enumeration { val GBP = Value("GBP") val EUR = Value("EUR") //etc.} 然后，您可以执行以下操作：
val ccy = Currency.withName("EUR")当希望保留枚举（例如，到数据库）或根据文件中的数据创建枚举时，此功能很有用。但是，我发现总体上来说，枚举在Scala中有点笨拙，并且具有附加组件的尴尬感，因此我现在倾向于使用case objects。Acase object比枚举更灵活：
sealed trait Currency { def name: String }case object EUR extends Currency { val name = "EUR" } //etc.case class UnknownCurrency(name: String) extends Currency所以现在我的优势是…
trade.ccy match { case EUR => case UnknownCurrency(pre) =>}正如@ chaotic3quilibrium指出的（为了便于阅读而进行了一些更正）：
关于“ UnknownCurrency（pre）”模式，除了“破坏”该Currency类型的封闭集性质外，还有其他方法可以解决找不到货币代码字符串的问题。UnknownCurrency类型Currency现在可以潜入API的其他部分。
最好将这种情况推到外面，Enumeration并让客户处理Option[Currency]明显表明确实存在匹配问题的类型，并“鼓励” API用户自行解决。
为了在此遵循其他答案，case objects over Enumerations的主要缺点是：
无法迭代“枚举”的所有实例。确实是这种情况，但是在实践中我发现极少需要这样做。
无法从持久值中轻松实例化。这也是正确的，但是，除非使用大量枚举（例如，所有货币），否则这不会带来巨大的开销。
