在Scala中，何时使用案例类(或案例对象)与扩展枚举有什么最佳实践指南吗?
它们似乎提供了一些相同的好处。
当前回答
更新: 一个新的基于宏的解决方案已经创建，它远远优于我下面概述的解决方案。我强烈推荐使用这种新的基于宏的解决方案。Dotty的计划似乎将使这种枚举解决方案成为语言的一部分。Whoohoo !
简介: 尝试在Scala项目中重现Java Enum有三种基本模式。三种模式中的两种;直接使用Java Enum和scala。枚举，不能启用Scala的穷举模式匹配。第三个;“密封特质+格对象”，是否…但是有JVM类/对象初始化的复杂性，导致不一致的序号索引生成。
I have created a solution with two classes; Enumeration and EnumerationDecorated, located in this Gist. I didn't post the code into this thread as the file for Enumeration was quite large (+400 lines - contains lots of comments explaining implementation context). Details: The question you're asking is pretty general; "...when to use caseclassesobjects vs extending [scala.]Enumeration". And it turns out there are MANY possible answers, each answer depending on the subtleties of the specific project requirements you have. The answer can be reduced down to three basic patterns.
首先，让我们确保使用的是与枚举相同的基本概念。让我们主要根据Java 5(1.5)提供的Enum定义一个枚举:
It contains a naturally ordered closed set of named members There is a fixed number of members Members are naturally ordered and explicitly indexed As opposed to being sorted based on some inate member queriable criteria Each member has a unique name within the total set of all members All members can easily be iterated through based on their indexes A member can be retrieved with its (case sensitive) name It would be quite nice if a member could also be retrieved with its case insensitive name A member can be retrieved with its index Members may easily, transparently and efficiently use serialization Members may be easily extended to hold additional associated singleton-ness data Thinking beyond Java's Enum, it would be nice to be able to explicitly leverage Scala's pattern matching exhaustiveness checking for an enumeration
接下来，让我们来看看三种最常见的解决方案模式: A)实际上直接使用Java Enum模式(在Scala/Java混合项目中):
public enum ChessPiece {
KING('K', 0)
, QUEEN('Q', 9)
, BISHOP('B', 3)
, KNIGHT('N', 3)
, ROOK('R', 5)
, PAWN('P', 1)
;
private char character;
private int pointValue;
private ChessPiece(char character, int pointValue) {
this.character = character;
this.pointValue = pointValue;
}
public int getCharacter() {
return character;
}
public int getPointValue() {
return pointValue;
}
}
枚举定义中的以下项不可用:
如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 7 -超越Java的Enum，如果能够显式地利用Scala的模式匹配耗尽性检查枚举就好了
对于我目前的项目，我没有在Scala/Java混合项目路径上冒险的好处。即使我可以选择做一个混合项目，如果/当我添加/删除枚举成员或编写一些新代码来处理现有的枚举成员时，第7项对于允许我捕获编译时问题也是至关重要的。 B)使用“密封特征+格对象”模式:
sealed trait ChessPiece {def character: Char; def pointValue: Int}
object ChessPiece {
case object KING extends ChessPiece {val character = 'K'; val pointValue = 0}
case object QUEEN extends ChessPiece {val character = 'Q'; val pointValue = 9}
case object BISHOP extends ChessPiece {val character = 'B'; val pointValue = 3}
case object KNIGHT extends ChessPiece {val character = 'N'; val pointValue = 3}
case object ROOK extends ChessPiece {val character = 'R'; val pointValue = 5}
case object PAWN extends ChessPiece {val character = 'P'; val pointValue = 1}
}
枚举定义中的以下项不可用:
1.2 -成员自然有序并显式建立索引 2 -所有成员都可以根据它们的索引进行迭代 成员可以通过其名称(区分大小写)进行检索 如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 成员可以用它的索引来检索
它确实符合枚举定义第5和6项，这是有争议的。对于5人来说，说它是有效的有点牵强。对于6来说，扩展以保存额外的关联单例数据并不容易。 C)使用scala。枚举模式(受StackOverflow的启发):
object ChessPiece extends Enumeration {
val KING = ChessPieceVal('K', 0)
val QUEEN = ChessPieceVal('Q', 9)
val BISHOP = ChessPieceVal('B', 3)
val KNIGHT = ChessPieceVal('N', 3)
val ROOK = ChessPieceVal('R', 5)
val PAWN = ChessPieceVal('P', 1)
protected case class ChessPieceVal(character: Char, pointValue: Int) extends super.Val()
implicit def convert(value: Value) = value.asInstanceOf[ChessPieceVal]
}
枚举定义中的以下项不可用(恰好与直接使用Java Enum的列表相同):
如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 7 -超越Java的Enum，如果能够显式地利用Scala的模式匹配耗尽性检查枚举就好了
同样，对于我当前的项目，第7项对于允许我在添加/删除枚举成员或编写一些新代码来处理现有枚举成员时捕获编译时问题至关重要。
因此，给定上面的枚举定义，以上三个解决方案都不能工作，因为它们不能提供上面枚举定义中概述的所有内容:
Java Enum直接在混合Scala/Java项目 “密封trait + case对象” scala。枚举
Each of these solutions can be eventually reworked/expanded/refactored to attempt to cover some of each one's missing requirements. However, neither the Java Enum nor the scala.Enumeration solutions can be sufficiently expanded to provide item 7. And for my own projects, this is one of the more compelling values of using a closed type within Scala. I strongly prefer compile time warnings/errors to indicate I have a gap/issue in my code as opposed to having to glean it out of a production runtime exception/failure.
在这方面，我开始使用case对象路径，看看是否可以生成一个涵盖上述所有枚举定义的解决方案。第一个挑战是解决JVM类/对象初始化的核心问题(在这篇StackOverflow文章中有详细介绍)。我终于找到了解决办法。
我的解决方案有两个特点;Enumeration和enumerationented，并且由于Enumeration trait超过+400行长(许多注释解释上下文)，我放弃将其粘贴到这个线程(这将使它延伸到页面相当大)。详情请直接跳到主旨。
下面是使用与上面相同的数据思想(此处提供完整的注释版本)并在enumerationdecoration中实现的解决方案。
import scala.reflect.runtime.universe.{TypeTag,typeTag}
import org.public_domain.scala.utils.EnumerationDecorated
object ChessPiecesEnhancedDecorated extends EnumerationDecorated {
case object KING extends Member
case object QUEEN extends Member
case object BISHOP extends Member
case object KNIGHT extends Member
case object ROOK extends Member
case object PAWN extends Member
val decorationOrderedSet: List[Decoration] =
List(
Decoration(KING, 'K', 0)
, Decoration(QUEEN, 'Q', 9)
, Decoration(BISHOP, 'B', 3)
, Decoration(KNIGHT, 'N', 3)
, Decoration(ROOK, 'R', 5)
, Decoration(PAWN, 'P', 1)
)
final case class Decoration private[ChessPiecesEnhancedDecorated] (member: Member, char: Char, pointValue: Int) extends DecorationBase {
val description: String = member.name.toLowerCase.capitalize
}
override def typeTagMember: TypeTag[_] = typeTag[Member]
sealed trait Member extends MemberDecorated
}
这是我创建的一对新枚举特征(位于Gist中)的示例使用，用于实现枚举定义中所期望和概述的所有功能。
所表达的一个关注点是枚举成员名必须重复(上面示例中的decorationOrderedSet)。虽然我确实把它减少到一次重复，但由于两个问题，我不知道如何让它更少:
这个特定对象/case对象模型的JVM对象/类初始化是未定义的(参见这个Stackoverflow线程) 方法getClass返回的内容。getDeclaredClasses有一个未定义的顺序(它不太可能与源代码中的case对象声明的顺序相同)
考虑到这两个问题，我不得不放弃尝试生成隐含的排序，而必须显式地要求客户端用某种有序集概念定义和声明它。由于Scala集合没有插入有序集实现，所以我能做的最好的事情就是使用List，然后运行时检查它是否真的是一个集合。这不是我想要的实现方式。
And given the design required this second list/set ordering val, given the ChessPiecesEnhancedDecorated example above, it was possible to add case object PAWN2 extends Member and then forget to add Decoration(PAWN2,'P2', 2) to decorationOrderedSet. So, there is a runtime check to verify that the list is not only a set, but contains ALL of the case objects which extend the sealed trait Member. That was a special form of reflection/macro hell to work through. Please leave comments and/or feedback on the Gist.
其他回答
与枚举相比，使用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).
一个很大的区别是枚举支持从某个名称String实例化它们。例如:
object Currency extends Enumeration {
val GBP = Value("GBP")
val EUR = Value("EUR") //etc.
}
然后你可以这样做:
val ccy = Currency.withName("EUR")
这在希望持久化枚举(例如，到数据库)或从驻留在文件中的数据创建枚举时非常有用。然而，我发现在Scala中枚举通常有点笨拙，给人一种笨拙的附加组件的感觉，所以我现在倾向于使用case对象。case对象比enum更灵活:
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(code) =>
}
正如@ chaotic3equilibrium所指出的(为了便于阅读，做了一些更正):
关于“UnknownCurrency(code)”模式，除了“破坏”currency类型的封闭集性质外，还有其他方法可以处理找不到货币代码字符串的问题。类型为Currency的UnknownCurrency现在可以潜入API的其他部分。 建议将这种情况推到枚举之外，并让客户端处理Option[Currency]类型，这将清楚地表明确实存在匹配问题，并“鼓励”API的用户自己进行排序。
为了跟进这里的其他答案，case对象相对于Enumerations的主要缺点是:
不能遍历“枚举”的所有实例。这当然是事实，但我发现在实践中很少需要这样做。 不容易从持久化值实例化。这也是正确的，但是，除了在大量枚举的情况下(例如，所有货币)，这并不会带来巨大的开销。
我更喜欢case对象(这是个人喜好的问题)。为了解决这种方法固有的问题(解析字符串并遍历所有元素)，我添加了一些不完美但有效的行。
我把代码粘贴在这里，希望它有用，也希望其他人可以改进它。
/**
* Enum for Genre. It contains the type, objects, elements set and parse method.
*
* This approach supports:
*
* - Pattern matching
* - Parse from name
* - Get all elements
*/
object Genre {
sealed trait Genre
case object MALE extends Genre
case object FEMALE extends Genre
val elements = Set (MALE, FEMALE) // You have to take care this set matches all objects
def apply (code: String) =
if (MALE.toString == code) MALE
else if (FEMALE.toString == code) FEMALE
else throw new IllegalArgumentException
}
/**
* Enum usage (and tests).
*/
object GenreTest extends App {
import Genre._
val m1 = MALE
val m2 = Genre ("MALE")
assert (m1 == m2)
assert (m1.toString == "MALE")
val f1 = FEMALE
val f2 = Genre ("FEMALE")
assert (f1 == f2)
assert (f1.toString == "FEMALE")
try {
Genre (null)
assert (false)
}
catch {
case e: IllegalArgumentException => assert (true)
}
try {
Genre ("male")
assert (false)
}
catch {
case e: IllegalArgumentException => assert (true)
}
Genre.elements.foreach { println }
}
更新: 一个新的基于宏的解决方案已经创建，它远远优于我下面概述的解决方案。我强烈推荐使用这种新的基于宏的解决方案。Dotty的计划似乎将使这种枚举解决方案成为语言的一部分。Whoohoo !
简介: 尝试在Scala项目中重现Java Enum有三种基本模式。三种模式中的两种;直接使用Java Enum和scala。枚举，不能启用Scala的穷举模式匹配。第三个;“密封特质+格对象”，是否…但是有JVM类/对象初始化的复杂性，导致不一致的序号索引生成。
I have created a solution with two classes; Enumeration and EnumerationDecorated, located in this Gist. I didn't post the code into this thread as the file for Enumeration was quite large (+400 lines - contains lots of comments explaining implementation context). Details: The question you're asking is pretty general; "...when to use caseclassesobjects vs extending [scala.]Enumeration". And it turns out there are MANY possible answers, each answer depending on the subtleties of the specific project requirements you have. The answer can be reduced down to three basic patterns.
首先，让我们确保使用的是与枚举相同的基本概念。让我们主要根据Java 5(1.5)提供的Enum定义一个枚举:
It contains a naturally ordered closed set of named members There is a fixed number of members Members are naturally ordered and explicitly indexed As opposed to being sorted based on some inate member queriable criteria Each member has a unique name within the total set of all members All members can easily be iterated through based on their indexes A member can be retrieved with its (case sensitive) name It would be quite nice if a member could also be retrieved with its case insensitive name A member can be retrieved with its index Members may easily, transparently and efficiently use serialization Members may be easily extended to hold additional associated singleton-ness data Thinking beyond Java's Enum, it would be nice to be able to explicitly leverage Scala's pattern matching exhaustiveness checking for an enumeration
接下来，让我们来看看三种最常见的解决方案模式: A)实际上直接使用Java Enum模式(在Scala/Java混合项目中):
public enum ChessPiece {
KING('K', 0)
, QUEEN('Q', 9)
, BISHOP('B', 3)
, KNIGHT('N', 3)
, ROOK('R', 5)
, PAWN('P', 1)
;
private char character;
private int pointValue;
private ChessPiece(char character, int pointValue) {
this.character = character;
this.pointValue = pointValue;
}
public int getCharacter() {
return character;
}
public int getPointValue() {
return pointValue;
}
}
枚举定义中的以下项不可用:
如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 7 -超越Java的Enum，如果能够显式地利用Scala的模式匹配耗尽性检查枚举就好了
对于我目前的项目，我没有在Scala/Java混合项目路径上冒险的好处。即使我可以选择做一个混合项目，如果/当我添加/删除枚举成员或编写一些新代码来处理现有的枚举成员时，第7项对于允许我捕获编译时问题也是至关重要的。 B)使用“密封特征+格对象”模式:
sealed trait ChessPiece {def character: Char; def pointValue: Int}
object ChessPiece {
case object KING extends ChessPiece {val character = 'K'; val pointValue = 0}
case object QUEEN extends ChessPiece {val character = 'Q'; val pointValue = 9}
case object BISHOP extends ChessPiece {val character = 'B'; val pointValue = 3}
case object KNIGHT extends ChessPiece {val character = 'N'; val pointValue = 3}
case object ROOK extends ChessPiece {val character = 'R'; val pointValue = 5}
case object PAWN extends ChessPiece {val character = 'P'; val pointValue = 1}
}
枚举定义中的以下项不可用:
1.2 -成员自然有序并显式建立索引 2 -所有成员都可以根据它们的索引进行迭代 成员可以通过其名称(区分大小写)进行检索 如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 成员可以用它的索引来检索
它确实符合枚举定义第5和6项，这是有争议的。对于5人来说，说它是有效的有点牵强。对于6来说，扩展以保存额外的关联单例数据并不容易。 C)使用scala。枚举模式(受StackOverflow的启发):
object ChessPiece extends Enumeration {
val KING = ChessPieceVal('K', 0)
val QUEEN = ChessPieceVal('Q', 9)
val BISHOP = ChessPieceVal('B', 3)
val KNIGHT = ChessPieceVal('N', 3)
val ROOK = ChessPieceVal('R', 5)
val PAWN = ChessPieceVal('P', 1)
protected case class ChessPieceVal(character: Char, pointValue: Int) extends super.Val()
implicit def convert(value: Value) = value.asInstanceOf[ChessPieceVal]
}
枚举定义中的以下项不可用(恰好与直接使用Java Enum的列表相同):
如果一个成员也可以用它不区分大小写的名字来检索，那就太好了 7 -超越Java的Enum，如果能够显式地利用Scala的模式匹配耗尽性检查枚举就好了
同样，对于我当前的项目，第7项对于允许我在添加/删除枚举成员或编写一些新代码来处理现有枚举成员时捕获编译时问题至关重要。
因此，给定上面的枚举定义，以上三个解决方案都不能工作，因为它们不能提供上面枚举定义中概述的所有内容:
Java Enum直接在混合Scala/Java项目 “密封trait + case对象” scala。枚举
Each of these solutions can be eventually reworked/expanded/refactored to attempt to cover some of each one's missing requirements. However, neither the Java Enum nor the scala.Enumeration solutions can be sufficiently expanded to provide item 7. And for my own projects, this is one of the more compelling values of using a closed type within Scala. I strongly prefer compile time warnings/errors to indicate I have a gap/issue in my code as opposed to having to glean it out of a production runtime exception/failure.
在这方面，我开始使用case对象路径，看看是否可以生成一个涵盖上述所有枚举定义的解决方案。第一个挑战是解决JVM类/对象初始化的核心问题(在这篇StackOverflow文章中有详细介绍)。我终于找到了解决办法。
我的解决方案有两个特点;Enumeration和enumerationented，并且由于Enumeration trait超过+400行长(许多注释解释上下文)，我放弃将其粘贴到这个线程(这将使它延伸到页面相当大)。详情请直接跳到主旨。
下面是使用与上面相同的数据思想(此处提供完整的注释版本)并在enumerationdecoration中实现的解决方案。
import scala.reflect.runtime.universe.{TypeTag,typeTag}
import org.public_domain.scala.utils.EnumerationDecorated
object ChessPiecesEnhancedDecorated extends EnumerationDecorated {
case object KING extends Member
case object QUEEN extends Member
case object BISHOP extends Member
case object KNIGHT extends Member
case object ROOK extends Member
case object PAWN extends Member
val decorationOrderedSet: List[Decoration] =
List(
Decoration(KING, 'K', 0)
, Decoration(QUEEN, 'Q', 9)
, Decoration(BISHOP, 'B', 3)
, Decoration(KNIGHT, 'N', 3)
, Decoration(ROOK, 'R', 5)
, Decoration(PAWN, 'P', 1)
)
final case class Decoration private[ChessPiecesEnhancedDecorated] (member: Member, char: Char, pointValue: Int) extends DecorationBase {
val description: String = member.name.toLowerCase.capitalize
}
override def typeTagMember: TypeTag[_] = typeTag[Member]
sealed trait Member extends MemberDecorated
}
这是我创建的一对新枚举特征(位于Gist中)的示例使用，用于实现枚举定义中所期望和概述的所有功能。
所表达的一个关注点是枚举成员名必须重复(上面示例中的decorationOrderedSet)。虽然我确实把它减少到一次重复，但由于两个问题，我不知道如何让它更少:
这个特定对象/case对象模型的JVM对象/类初始化是未定义的(参见这个Stackoverflow线程) 方法getClass返回的内容。getDeclaredClasses有一个未定义的顺序(它不太可能与源代码中的case对象声明的顺序相同)
考虑到这两个问题，我不得不放弃尝试生成隐含的排序，而必须显式地要求客户端用某种有序集概念定义和声明它。由于Scala集合没有插入有序集实现，所以我能做的最好的事情就是使用List，然后运行时检查它是否真的是一个集合。这不是我想要的实现方式。
And given the design required this second list/set ordering val, given the ChessPiecesEnhancedDecorated example above, it was possible to add case object PAWN2 extends Member and then forget to add Decoration(PAWN2,'P2', 2) to decorationOrderedSet. So, there is a runtime check to verify that the list is not only a set, but contains ALL of the case objects which extend the sealed trait Member. That was a special form of reflection/macro hell to work through. Please leave comments and/or feedback on the Gist.
推荐文章
- case对象和对象的区别
- Scala中的Case对象与枚举
- 任务不可序列化:java.io.NotSerializableException，当只对类而不是对象调用闭包外部的函数时
- 在Scala中将一个元素附加到列表的末尾
- 在Scala中按名称调用vs按值调用，需要澄清
- 解析命令行参数的最佳方法?
- Android Scala编程
- lazy val做什么?
- Scala:抽象类型vs泛型
- 如何在准引用中使用无形?
- “map”方法在Ruby中做什么?
- Scala中方法和函数的区别
- Scala中的“提升”是什么?
- 为Objective-C中的每个循环访问NSMutable字典
- 什么是Scala上下文和视图边界?
