精选枚举代替开关

问题及其解决方案

开关/案例是用大多数命令式编程语言实现的通用控制结构。开关比一系列的if / else更具可读性。

这是一个简单的示例：

// Switch with int literal
switch (c) {case 1: one(); break;case 2: two(); break;case 3: three(); break;default: throw new UnsupportedOperationException(String.format("Operation %d is not supported", c));
}

这是此代码中的主要问题的列表：

int文字（1、2、3）与执行的代码之间的关系并不明显。
如果不再支持其中一个值（例如2），并且此开关未相应更新，它将永远包含未使用的代码。
如果引入了c的新可能值（例如4），并且未相应更新开关，则代码可能会在运行时抛出UnsupportedOperationException而没有任何编译时通知。
这种开关结构倾向于在代码中重复几次，从而使问题2和3更加复杂。

最简单的解决方法是使用int常量而不是文字。首先，让我们定义常量：

private static int ONE = 1;
private static int TWO = 2;
private static int THREE = 3;

现在，代码将如下所示：

switch (c) {case ONE: one(); break;case TWO: two(); break;case THREE: three(); break;default: throw new UnsupportedOperationException(String.format("Operation %d is not supported", c));
}

（显然，在现实生活中，常量的名称必须是自描述的）

此代码段更具可读性，但所有其他缺点仍然相关。改进初始代码段的下一个尝试使用2004年在版本5中引入Java语言的enums 。让我们定义以下enum ：

enum Action {ONE, TWO, THREE}

现在，开关片段将稍作更改：

Action a = ...
switch (a) {case ONE: one(); break;case TWO: two(); break;case THREE: three(); break;default: throw new UnsupportedOperationException(String.format("Operation %s is not supported", a));
}

这段代码要好一点：如果从enum Action删除其中一个元素，它将产生编译错误。但是，如果将其他元素添加到enum Action ，则不会导致编译错误。在这种情况下，某些IDE或静态代码分析工具可能会产生警告，但是谁在注意警告呢？幸运的是， enum可以声明必须由每个元素实现的抽象方法：

enum Action {ONE { @Override public void action() { } }, TWO { @Override public void action() { } }, THREE { @Override public void action() { } }, public abstract void action();
}

现在，switch语句可以用单行替换：