我在这里有一个简单的库，允许你使用密封的trait /类作为枚举值，而不必维护自己的值列表。它依赖于一个简单的宏，不依赖于有bug的knownDirectSubclasses。

https://github.com/lloydmeta/enumeratum

Case对象已经为它们的toString方法返回它们的名称，因此单独传入它是不必要的。下面是一个类似于jho的版本(为简洁起见，省略了方便方法):

trait Enum[A] {
  trait Value { self: A => }
  val values: List[A]
}

sealed trait Currency extends Currency.Value
object Currency extends Enum[Currency] {
  case object EUR extends Currency
  case object GBP extends Currency
  val values = List(EUR, GBP)
}

对象是懒惰的;通过使用vals，我们可以删除列表，但必须重复名称:

trait Enum[A <: {def name: String}] {
  trait Value { self: A =>
    _values :+= this
  }
  private var _values = List.empty[A]
  def values = _values
}

sealed abstract class Currency(val name: String) extends Currency.Value
object Currency extends Enum[Currency] {
  val EUR = new Currency("EUR") {}
  val GBP = new Currency("GBP") {}
}

如果不介意作弊，可以使用反射API或谷歌Reflections之类的东西预加载枚举值。非惰性大小写对象提供了最简洁的语法:

trait Enum[A] {
  trait Value { self: A =>
    _values :+= this
  }
  private var _values = List.empty[A]
  def values = _values
}

sealed trait Currency extends Currency.Value
object Currency extends Enum[Currency] {
  case object EUR extends Currency
  case object GBP extends Currency
}

漂亮而干净，具有case类和Java枚举的所有优点。就我个人而言，我在对象之外定义枚举值，以更好地匹配惯用的Scala代码:

object Currency extends Enum[Currency]
sealed trait Currency extends Currency.Value
case object EUR extends Currency
case object GBP extends Currency

与枚举相比，使用case类的优点是:

当使用密封大小写类时，Scala编译器可以判断匹配是否完全指定，例如，当所有可能的匹配都支持在匹配声明中。对于枚举，Scala编译器无法判断。 Case类自然比支持名称和ID的基于值的枚举支持更多的字段。

使用枚举而不是case类的优点是:

枚举通常需要编写更少的代码。 对于Scala新手来说，枚举比较容易理解，因为它们在其他语言中很普遍

所以一般来说，如果你只需要一个简单的常量列表的名称，使用枚举。否则，如果你需要一些更复杂的东西，或者想要编译器告诉你是否指定了所有匹配的额外安全，用例类。

2017年3月更新:正如Anthony Accioly所评论的，scala。枚举/枚举PR已关闭。

Dotty (Scala的下一代编译器)将占据主导地位，尽管Dotty发行于1970年，Martin Odersky的PR发行于1958年。

注意:现在(2016年8月，6年多之后)有一个移除scala的提案。编号:PR 5352

scala抨击。枚举，添加@enum注释 的语法

@enum
 class Toggle {
  ON
  OFF
 }

是一个可能的实现示例，目的是也支持符合某些限制(没有嵌套，递归或变化的构造函数参数)的adt，例如:

@enum
sealed trait Toggle
case object ON  extends Toggle
case object OFF extends Toggle

Deprecates the unmitigated disaster that is scala.Enumeration. Advantages of @enum over scala.Enumeration: Actually works Java interop No erasure issues No confusing mini-DSL to learn when defining enumerations Disadvantages: None. This addresses the issue of not being able to have one codebase that supports Scala-JVM, Scala.js and Scala-Native (Java source code not supported on Scala.js/Scala-Native, Scala source code not able to define enums that are accepted by existing APIs on Scala-JVM).

如果你想要维护与其他JVM语言(如Java)的互操作性，那么最好的选择是编写Java枚举。这些功能在Scala和Java代码中都可以透明地工作，这在Scala中是做不到的。枚举或case对象。如果可以避免的话，让我们不要为GitHub上的每个新爱好项目都创建一个新的枚举库!

我认为与枚举相比，使用case类的最大优点是可以使用类型类模式，也就是ad-hoc polymorphysm。不需要像这样匹配枚举:

someEnum match {
  ENUMA => makeThis()
  ENUMB => makeThat()
}

相反，你会看到如下内容:

def someCode[SomeCaseClass](implicit val maker: Maker[SomeCaseClass]){
  maker.make()
}

implicit val makerA = new Maker[CaseClassA]{
  def make() = ...
}
implicit val makerB = new Maker[CaseClassB]{
  def make() = ...
}