扩展枚举功能的两种方法

前言

在上一篇文章中，我解释了如何以及为什么在Java代码中使用enums而不是switch/case控制结构。在这里，我将展示如何扩展现有enums功能。

介绍

Java enum是一种编译器魔术。在字节码中，任何enum都表示为扩展抽象类java.lang.Enum并具有几个静态成员的类。因此，枚举不能扩展任何其他类或枚举：没有多重继承。

类也不能扩展枚举。此限制由编译器强制执行。

这是一个简单的enum ：

 enum Color {red, green, blue}

此类尝试扩展它：

 SubColor class extends Color {}

这是尝试编译类SubColor的结果：

 $ javac SubColor.java  SubColor.java: 1 : error: cannot inherit from final Color  SubColor class extends Color {} ^  SubColor.java: 1 : error: enum types are not extensible  SubColor class extends Color {}  ^  2 errors

Enum既不能扩展也不能扩展。那么，如何扩展其功能呢？关键字是“功能”。 Enum可以实现方法。例如，枚举Color可以声明抽象方法draw() ，每个成员都可以重写它：

enum Color {red { @Override public void draw() { } },green { @Override public void draw() { } },blue { @Override public void draw() { } },;public abstract void draw();
}

在此说明该技术的流行用法。不幸的是，不可能总是在枚举本身中实现方法，因为：

枚举可能属于第三方库或公司中的其他团队
枚举可能被过多的其他数据和函数重载，因此变得不可读
枚举属于模块，该模块不具有实现方法draw（）所需的依赖项。

本文针对此问题提出了以下解决方案。

镜像枚举

我们不能修改枚举颜色吗？没问题！让我们创建具有与Color完全相同的元素的枚举DrawableColor。这个新的枚举将实现我们的方法draw（）：

enum DrawableColor {red { @Override public void draw() { } },green { @Override public void draw() { } },blue { @Override public void draw() { } },;public abstract void draw();
}

这个枚举是源枚举Color的一种反映，即Color是它的镜像。但是如何使用新的枚举？我们所有的代码都使用Color而不是DrawableColor 。实现此过渡的最简单方法是使用内置的枚举方法name（）和valueOf（），如下所示：

Color color = ...
DrawableColor.valueOf(color.name()).draw();

由于name()方法是最终方法，不能被覆盖，并且valueOf()由编译器生成，因此这些方法始终相互配合，因此在此不会出现功能问题。这种过渡的性能也很好：方法name（）甚至不创建新的String而是返回预初始化的String（请参见java.lang.Enum源代码）。方法valueOf()是使用Map实现的，因此其复杂度为O（1）。

上面的代码包含明显的问题。如果更改了源枚举Color，则辅助枚举DrawableColor将不知道这一事实，因此具有name()和valueOf()的技巧将在运行时失败。我们不希望这种情况发生。但是如何防止可能的故障？

我们必须让DrawableColor知道其镜像是Color，并且最好在编译时或至少在单元测试阶段强制执行此操作。在这里，我们建议在单元测试执行期间进行验证。 Enum可以实现时所执行的静态初始化enum中的任何代码被提及。这实际上意味着，如果静态初始化程序验证枚举DrawableColor是否适合Color，则足以执行以下测试，以确保代码不会在生产环境中被破坏：

@Test
public void drawableColorFitsMirror {DrawableColor.values();
}

静态初始化器只需要比较DrawableColor和Color元素，如果不匹配则抛出异常。该代码很简单，可以针对每种特定情况编写。幸运的是，名为enumus的简单开放源代码库已经实现了此功能，因此任务变得微不足道：

enum DrawableColor {....static {Mirror.of(Color.class);}
}

而已。如果源枚举和DrawableColor不再适合，则测试将失败。实用程序类Mirror其他方法有2个参数：必须包含2个枚举的类。可以从代码中的任何位置调用此版本，而不仅仅是从必须经过验证的枚举中调用。

枚举地图

我们是否真的必须定义仅包含一种方法的实现的另一个枚举？实际上，我们不必这样做。这是一个替代解决方案。让我们定义接口抽屉如下：

public interface Drawer {void draw();
}

现在让我们在枚举元素和接口Drawer的实现之间创建映射：

Map<Color, Drawer> drawers = new EnumMap<>(Color.class) {{put(red, new Drawer() { @Override public void draw();});put(green, new Drawer() { @Override public void draw();})put(blue, new Drawer() { @Override public void draw();})
}}

用法很简单：

 drawers.get(color).draw();

这里选择EnumMap作为Map实现，以获得更好的性能。 Map保证每个枚举元素仅出现一次。但是，它不能保证每个enum元素都有相应的条目。但是检查映射的大小等于enum元素的数量就足够了：

 drawers.size() == Color.values().length

枚举还建议在这种情况下方便实用。如果地图不适合Color，则以下代码将引发IllegalStateException及其描述性消息：

 EnumMapValidator.validateValues(Color. class , map, "Colors map" );

从单元测试执行的代码中调用验证器很重要。在这种情况下，基于地图的解决方案对于将来对源枚举的修改是安全的。

EnumMap和Java 8功能接口

实际上，我们不必定义特殊的接口来扩展
枚举功能。从版本8开始，我们可以使用JDK提供的功能接口之一（ Function,BiFunction,Consumer,BiConsumer, Supplieretc Function,BiFunction,Consumer,BiConsumer, Supplieretc Function,BiFunction,Consumer,BiConsumer, Supplieretc 。）选择取决于必须发送给功能的参数。例如，可以使用Supplier代替上一个示例中定义的Drawable ：

 Map<Color, Supplier<Void>> drawers = new EnumMap<>(Color. class ) {{ put(red, new Supplier<Void>() { @Override public void get();}); put(green, new Supplier<Void>() { @Override public void get();}) put(blue, new Supplier<Void>() { @Override public void get();})  }}

该映射的用法与上一个示例非常相似：