一个枚举类型是一种类型，它的合法值由一组固定的常量组成，比如一年中的季节，太阳系的行星或一副扑克牌的套装。在枚举类型添加到语言之前，表示枚举类型的一个常见模式是声明一组命名的int常量，其中一个对应于该类型的每个成员：
这个技巧，叫作int枚举模式，有很多缺点。它没有提供任何形式的类型安全，在表达能力方面几乎没有提供任何东西。如果你编写一个apple传递给方法期望得到orange的方法，编译器不会抱怨，使用==操作符将apple与orange比较，或更糟的是：
注意到每个apple常量的前缀都是APPLE_ 以及每个orange常量的前缀是 ORANGE_ 。这是因为Java没有为这些int枚举组提供命名空间。前缀防止命名冲突，当两个int枚举组具有同名常量时，比如，ELEMENT_MERCURY和ELEMENT_MERCURY。
使用int枚举的程序是脆弱的。因为int枚举是常量变量 [JLS, 4.12.4]，所以它们的int值被编译到它们的客户机中使用[JLS, 13.1]。如果与int枚举关联的值被更改，它的客户端必须重新编译。如果不这么做，客户端将还能允许，但是它们的行为会变得不正确。
要将int枚举常量转换为可打印的字符串，没有简单的方法。如果你打印这样一个常量或者从调试器中显示它，你所看到的是一个树资，这没有多大帮助。没有可靠的方法来迭代组中所有int枚举常量，甚至无法获取int emum组的大小。
你可能会遇到这种模式的变体使用String常量代替int常量。这种变体，称为String枚举模式，甚至更糟糕。虽然它确实为它的常量提供了可打印的字符串，但是它引导天真的用户使用硬编码的字符串常量到客户端代码而不是使用字段名。如果这样的硬编码字符串包含了银沙错误，它将在编译时逃避检测，并在运行时导致错误。此外，它还会导致性能问题，因为它依赖于字符串比较。
幸运的是，Java提供了一个替代方法来避免int和string枚举模式的所有缺点并提供了许多好处。它就是枚举类型 [JLS, 8.9]。如下是它最简单的形式：
表面上，这些枚举类型和其他语言例如C，C++,C#类似，但是外表是骗人的。Java的枚举类型是完全成熟的类，比它们在其他语言中的对应类要强大得多，在这些语言中，枚举本质上是int值。
Java枚举类型的基本思想很简单：它们是通过公共静态final字段为每个枚举常量导出一个实例的类。由于没有可访问的构造方法，Enum类型实际上是final的。因为客户端既不能创建枚举类型的实例，也不能继承它，所以除了声明的枚举常量之外，不可能有实例。换句话说，枚举类型是由实例控制的（page6）.它们是单例的，本质伤是但元素枚举。
枚举提供了编译时的类型安全。如果你声明一个参数类型是Apple，你可以保证传递给该参数的任何非空对象引用都是三个有效Apple值之一。尝试传递错误类型的值将造成编译时错误，尝试将一种枚举类型的表达式分配给另一种类型的变量，或使用==运算符来比较不同枚举类型的值。
同名常量的枚举类型能够和平共处因为每个类型都有自己的命名空间。你可以在枚举类型中添加或重新排序常量，而无需重新编译其客户端，因为导出常量的字段提供了枚举类型与客户端之间的隔离层：常量值不会像它们在int枚举模式中那样被编译到客户机中。最后，你可以通过调用toString方法翻译枚举为可打印的字符串。
除了纠正int枚举的缺陷以外，枚举类型还允许你添加任何方法和字段，并实现任意接口。它们提供了所有对象方法的高质量实现（Chapter3）,它们实现Compareble((https://www.jianshu.com/p/53a7c1241240) )和Serializable(Chapter12)，它们的序列化形式被设计成能够承受对枚举类型的大多数更改。
那么，为什么要将方法或字段添加到枚举类型中？首先，你可能想要将数据与其常量关联起来。我们的Apple类型和Orange类型，比如，可以受益于返回水锅颜色的方法或返回它的图像的方法。你可以使用任何看起来合适的方法来增加枚举类型。枚举类型可以作为枚举常量的简单集合开始生命，并随着时间的推移演变为功能齐全的抽象。
举一个丰富的枚举类型的好例子，考虑我们太阳系的八颗行星。每个行星都有质量和半径，从这两个属性你可以计算它的表面重力。这反过来能让你计算行星表面物体的重量，给定物体的质量。如下是枚举的样子。每个枚举常量后面的括号中的数字是传递给其构造方法的参数。在这个情况下，它们是行星的质量和半径.
很容易编写一个富枚举类型比如Planet。若要将数据和枚举常量关联起来，声明实例字段，编写一个构造方法来接受数据并在字段中存储。Enum在本质伤是不可变的，所以所有字段应该是final的（item17）。字段可以是公有的，但是最好让它们是私有的并提供公有的访问器（item16 ）。在Planet的情况，构造方法也计算并存储了表面重力，但这只是一个优化。重力可以被重新计算在surfaceWeight方法中使用质量和半径，由常数表示。
虽然Planet枚举是简单的，但它还是很强大的。这是一个简短的程序，它可以计算一个物体的重量（以任何单位计算）并在所有八个行星上（在同一单位上）打印一个好的物体重量表：
请注意，与所有枚举一样，Planet由一个静态值方法，按照声明的顺序返回其值的数组。还请注意，toString方法返回每个枚举值的声明名称，允许println和print轻松打印。如果你对这个字符串表示不满意，你可以通过覆写toString方法来改变它。下面是使用命令行参数185运行WeightTable程序（不覆写toString）的结果：
在2006年之前，也就是Java加入枚举的两年后，Pluto还是是一个行星。这就上升了一个问题“当你在一个枚举类型中移除了元素会发生什么？”。答案是，任何不引用已删除元素的客户端程序都将继续正常工作。所以，比如，WeightTable程序只会简单地打印少一行的表。引用已删除的客户端程序（在本例中是Planet.Pluto）怎么办？如果你重新编译客户端程序，编译将失败并打印一个有用的错误消息，引用了旧行星；如果你未能重新编译客户端，它将在运行时从该行抛出一个有用的异常。这是你所希望得到的最好的行为，远比在int枚举模式中得到的要好很多。
某些与枚举常量相关的行为可能只需要在类定义枚举的类或包中使用。这些行为最好作为私有或包私有方法来实现。每个常量都带有一个隐藏的行为集合，允许包含枚举的类或包在呈现常量时做出适当的反应。与其他类一样，除非你由令人信服的理由将枚举方法公开给它的客户端，否则声明它是私有的，或者有需要的话，声明包私有（item15）
如果枚举通常是有用的，它应该是一个顶级类；如果它的使用与特定的顶级类相关联，那么应该是该顶级类的成员类（item24）。例如， java.math.RoundingMode枚举代表了十进制分数的舍入模式。这个舍入模式用于BigDecimal类，但是它们提供了一个与BigDecimal没有根本联系的有用的抽象。通过使RoundingMode称为顶级枚举，库设计人员鼓励任何需要舍入模式的程序员重用该枚举，以提高API之间的一致性。
在Planet例子中演示的技术足以满足大多数枚举类型，但有时候你需要更多。每个行星尝试都有不同的数据，但有时候你需要将根本不同的行为与每个常数相关联。比如，假设你正在编写一个枚举类型来代表基本四则运算计算机上的操作，并且你想要提供方法来执行由每个常量表示的算数运算。实现这一目标的一种方法是打开枚举的值：
这个代码可以工作，但是并不漂亮。它不会在没有抛出语句的情况下编译，因为该方法的结尾在技术上是可达到的，即使永远不会到达 [JLS, 14.21]。更糟糕的是，代码是脆弱的。如果你添加了一个新的枚举常量，但忘记向switch添加相应的情况，则枚举仍然会编译，但是当你尝试应用新操作时，它将在运行时失败。
幸运的是，有一种更好的方法可以将不同的行为与每个枚举常量关联起来：在枚举类型中声明一个抽象的应用方法，并未一个特定于常量的类体中的每个常量使用一个具体的方法来覆写它。这样的方法被称为常量特定的方法实现：
如果你在Operation的第二个版本中加入新的常量，你就不会忘记提供apply方法，因为方法紧跟着每个常量声明。在不太可能忘记的情况下，编译器会提醒你，因为枚举类型中的抽象方法必须被所有常量中的具体方法覆写。
特定于常量的方法实现可以与特定于常量的数据相结合。例如，下面的Operation版本，它覆写了toString方法来返回与该操作关联的符号：
如下面这个小程序所示，toString实现可以方便地打印算数表达式：
使用2和4作为命令行参数运行该程序将产生以下输出：
枚举类型有一个自动生成的valueOf(String)方法，该方法将常量的名称转换为常量本身。如果你在一个枚举类型中覆写toString方法，考虑编写一个fromString方法将自定义字符串表示形式转换回相应的枚举。下列代码（类型名称已适当更改）将对任何枚举都起作用，只要每个常量都有一个唯一的字符串表示形式：
注意，Operation常量是从创建枚举常量之后运行的静态字段初始化输入到字符串toEnum Map中的。前面的代码使用流（Chapter7）通过values()返回数组的值。在Java8之前，我们将创建一个空的散列映射，并迭代将字符串到枚举映射插入到映射中的值数组，如果愿意的话，仍然可以这么做。但是注意，尝试让每个常量从它自己的构造方法映射到一个映射中是无法工作的。这将导致编译错误，这是一件好事，因为如果它是合法的，它将在运行时造成NullPointerException。枚举构造方法不允许访问枚举的枚举的静态字段，常数变量除外（item34）。这个限制是必要的，因为在运行枚举构造方法时并没有初始化静态字段。这种限制的特例是枚举常量不能从它们的构造方法中相互访问。
也需要注意到fromString方法返回了一个Optional<String>。这允许方法指示传入的字符串不代表有效的操作，并迫使客户端面对这种可能性（item55 ）
特定于常量的方法实现的一个缺点是它们使得在枚举常量之间共享代码变得更加困难了。例如，考虑在薪资包中表示一周的天数的枚举。这个枚举有一个方法，根据工人的基本工资（每小时）和当天工作的分钟数，计算该天的工人工资。在五个工作日，任何超过正常轮班的工作时间都会产生加班费。在两个周末日，所有工作都有加班费。使用switch描述，它很容易通过多个用例标签应用于两个代码片段中的每一个来实现这个计算：
这段代码无可否认是简洁的，但从维护的角度看是危险的。假设你向枚举添加了一个元素，可能是一个表示假期的特殊值，但是忘记向switch语句添加相应的大小写。程序仍将编译，但薪资方法将默默地支付给员工的假期金额与普通工作日相同。
为了使特定于常量的方法实现安全地执行薪资计算，你将不得不重复计算每个常数的加班费，或将计算移动到两个helper方法中，平日和周末各一次，并从每个常量中调用适当的helper方法。这两种方法都会产生相当数量的样板代码，大大地减少可读性，增加了出错机会。
可以通过用PayrollDay的具体方法来替换抽象overtimePay方法来减少样板。那么只有周末才需要重写该方法。但是这与Switch语句具有相同的缺点：如果添加了新一天而不覆写overtimePay方法，你还是要默默地继承工作日计算。
你真正想要的是，每次添加枚举常量时，都必须选择加班费策略。幸运的是，有一个很好的方法来实现这一点。其思想是将加班费计算移动到一个私有嵌套枚举中，并将此策略枚举的一个实例传递给PayrollDay枚举的构造方法。然后PayrollDat枚举将加班费计算委托给策略枚举，从而无需在PayrollDay中使用switch语句或特定于常量的方法实现。虽然这种模式不像switch语句那么简洁，但它更安全，更灵活：
如果枚举上的switch语句不商在枚举上实现特定于常量行为的好选择，那它们有什么好处？在枚举上的Switch有利于增强特定于常量行为的枚举类型。比如，假设Operation枚举不在你的控制之下，你希望它有一个实例方法来返回每个操作的逆操作。你可以使用以下静态方法来模拟效果：
如果方法根本不属于枚举类型，那么你还应该在你控制的枚举类型上使用此技术。该方法可能是某些用途所必需的，但通常还不够有用，不值得包含在枚举类型中。一般来说，枚举的性能与int常量相当。枚举的一个较小的性能缺点是加载和初始化枚举类型需要占用空间和时间，但在实际中不太可能引起注意。
那么，什么时候该用枚举？在需要一组常量时使用枚举，这些常量的成员在编译时是已知的。当然，这包括了“自然枚举类型”，比如行星，一周的每天，以及棋子。但它也包括其他你任何在编译时就知道的值，比如菜单上的选择，操作码，和命令行标志。枚举中的一组常量不必一直保持固定状态。枚举的特性就是为了允许枚举类型的二进制兼容演化而设计的。
总之，枚举类型比int常量更有优势。枚举更可读，更安全，更强大。许多枚举不需要显式构造方法或成员，但其他枚举则受益于将数据与每个常量关联，并提供其行为受此数据影响的 方法。更少的枚举受益于将多个行为与单个方法相关联。在这种相对罕见的情况下，更喜欢特定于常量的方法，而不是witch它们自己的值。考虑一下策略枚举模式，如果某些（而不是全部）枚举常量有共同的行为。
本文写于2019.7.5，历时4天
