扩展方法 枚举值_扩展枚举功能的两种方法

扩展方法 枚举值

前言

在上一篇文章中，我解释了如何以及为什么在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();
}

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

1. 枚举可能属于第三方库或公司中的其他团队
2. 枚举可能被过多的其他数据和函数重载，因此变得不可读
3. 枚举属于不具有实现方法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而是返回预先初始化的字符串（请参见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();})  }} 

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

 drawers.get(color).get(); 

该地图可以与存储以下实例的地图完全一样地进行验证：
可绘制。

结论

本文说明了如果我们在其中添加一些逻辑，那么Java enums有多么强大。 它还演示了两种扩展语言enums功能的方法，尽管存在语言限制。 本文向用户介绍了名为enumus的开源库，该库提供了几个有用的实用工具，这些工具有助于简化 enums操作。

翻译自: https://www.javacodegeeks.com/2019/03/two-ways-extend-enum-functionality.html

扩展方法 枚举值