几乎在所有方面，枚举类型描述的类型安全枚举模式比本书第一版描述更优 [Bloch01]。从表面上看，有一个例外涉及了可扩展性，它在原始模式下是支持的，但不受语言结构的支持。换句话说，使用这个模式，可以让一个枚举类型扩展另一个枚举类型；但在语言特性上，它不可以。这不是意外。在大多数清空下，枚举的可扩展性被证明是一个坏主意。令人困惑的是，扩展类型的元素是基本类型的实例，反之亦然。没有一种好的方法来枚举基类型及其扩展的所有元素。最后，可扩展性将使设计和实现的许多方面复杂化。
也就是说，对于可扩展枚举类型，至少有一个可令人信服的用例，叫作operation codes，也叫作 opcodes. opcode是一种枚举类型，其元素表示一些及机器上的操作，比如Item34的代表了简单计算的Operation 类型。有时候需要让API的用户提供自己的操作，从而有效地扩展API提供的操作集。
幸运的是，有一种很好的方法可以使用枚举类型来实现这种效果。其基本思想是利用枚举类型可以通过为操作码类型定义接口和为接口的标准实现定义枚举来实现任意接口这一事实。比如，这是item34的Operation类型的扩展版本：
虽然枚举类型（BasicAction）不可扩展，但接口类型（Operation）是可扩展的，接口类型用于表示API中的操作。你可以定义实现该接口的另一个枚举类型，并使用此新类型的实例来代替基类型。例如，假设要定义前面显示的操作类型的扩展，包括幂运算和余数运算。所有要做的就算编写一个实现操作接口的枚举类型：
现在你可以在可以使用基本操作的任何地方使用你的新操作，条件是编写API是接口接口类型（Operation）而不是采用实现（BaseOperation）。注意到你并不需要不得不在枚举中声明抽象apply方法，就像之前不能继承的枚举那样特定实例的方法实现（page162）.这是因为抽象方法（apply）是接口的成员（Operation）.
不仅可以在任何需要“基枚举”的地方传递“扩展枚举”的单个实例，而且还可以传递整个扩展枚举类型，并在基类型之外使用其元素或替代基类型的元素。例如，下面是page163测试程序的一个版本，它执行前面定义的所有扩展操作：
注意到扩展操作类型（ExtendedOperation.class）的类文字从main传递到测试，以描述扩展操作类。类文字充当有界类型标记（ item33）。对于opEnumType参数（<T extends Enum<T> & Operation> Class<T>)的复杂声明确保Class对象同时表示操作的枚举和子类型，这正是迭代元素和执行与每个元素关联的操作所需的。
第二个选择是传递一个Collection<? extends Operation>，它是一个有界通配符类型（item31），而不是传递一个类对象：
生成的代码不那么复杂，测试方法也更灵活一些：它允许调用者组合多个实现类型的操作。另一方面，你放弃了在指定操作中使用EnumSet（item36）和EnumMap(item37)的能力。
在使用命令行参数4和2运行时，前面展示的两个程序都将产生此输出：
使用接口模拟可扩展枚举的一个小缺点是实现不能从一种枚举类型继承到另一种类型。如果实现代码不依赖于任何状态，那么它就可以使用默认实现（item20）被放置在接口中。在我们的操作示例中，存储和检索与操作相关的符号的逻辑必须在BasicOperation和ExtendedOperation中一致。在这种清空下这不是问题因为只有一点点代码重复。如果有很大数量的共享功能，则可以将其封装在helper类或静态helper中，以消除代码重复。
本item描述的模式在Java库中就使用了。比如 java.nio.file.LinkOption枚举类型实现了CopyOption和OpenOption接口。
总之，虽然你不能编写一个可扩展的枚举类型，但是你还能通过编写一个接口来模拟它，以配合实现该接口的基本枚举类型。这允许客户端编写自己的枚举类型（或其他类型）来实现接口的实现。假设API是按照接口写的，那么这些类型的实例可以在任何可以使用基本枚举类型的实例的地方使用。
本文写于2019.7.9，历时1天
