枚举是什么

enum是为枚举定义的关键字，是一种新的数据类型。应该广泛使用类型安全枚举。特别是，它们是较老api中用来表示相关项集的简单String或int常量的健壮替代。

为什么使用enum

enum是java.lang.Enum的隐式final子类 如果枚举是类的成员，则它是隐式静态的 New永远不能用于枚举，即使是在枚举类型本身中 name和valueOf简单地使用枚举常量的文本，而toString可以被覆盖以提供任何内容，如果需要的话 对于枚举常量，equals和==等于同一个东西，并且可以互换使用 枚举常量是隐式的公共静态final

Note

枚举不能扩展任何类。 enum不能是超类。 枚举常量的出现顺序被称为它们的“自然顺序”，并定义了其他项使用的顺序:compareTo，值的迭代顺序，EnumSet, EnumSet.range。 枚举可以有构造函数、静态和实例块、变量和方法，但不能有抽象方法。

这里有很多答案，只想指出两个具体的:

1)在Switch-case语句中作为常量使用。 Switch case不允许使用String对象作为case。枚举可以派上用场。更多:http://www.javabeat.net/2009/02/how-to-use-enum-in-switch/

2)再次实现单例设计模式- Enum，来拯救。这里的用法:在Java中使用Enum作为单例的最佳方法是什么?

当一个变量(特别是一个方法参数)只能从一组可能的值中选取一个时，您应该始终使用枚举。例如类型常量(合约状态:“永久”，“临时”，“学徒”)或标志(“立即执行”，“延迟执行”)。

如果使用枚举而不是整数(或字符串代码)，则增加了编译时检查，避免了传入无效常量的错误，并且记录了哪些值是可以合法使用的。

顺便说一句，过度使用枚举可能意味着你的方法做了太多的事情(通常有几个单独的方法会更好，而不是一个方法有几个标记来修改它所做的事情)，但如果你必须使用标记或类型代码，枚举是最好的选择。

举个例子，哪个更好?

/** Counts number of foobangs.
 * @param type Type of foobangs to count. Can be 1=green foobangs,
 * 2=wrinkled foobangs, 3=sweet foobangs, 0=all types.
 * @return number of foobangs of type
 */
public int countFoobangs(int type)

与

/** Types of foobangs. */
public enum FB_TYPE {
 GREEN, WRINKLED, SWEET, 
 /** special type for all types combined */
 ALL;
}

/** Counts number of foobangs.
 * @param type Type of foobangs to count
 * @return number of foobangs of type
 */
public int countFoobangs(FB_TYPE type)

方法调用如下:

int sweetFoobangCount = countFoobangs(3);

然后就变成:

int sweetFoobangCount = countFoobangs(FB_TYPE.SWEET);

在第二个例子中，很明显哪些类型是允许的，文档和实现不能不同步，编译器可以强制执行这一点。 另外，无效调用

int sweetFoobangCount = countFoobangs(99);

已经不可能了。

在我看来，你到目前为止的所有答案都是正确的，但根据我的经验，我想用几句话来表达:

如果希望编译器检查标识符值的有效性，请使用枚举。

否则，您可以像往常一样使用字符串(可能您为应用程序定义了一些“约定”)，并且您将非常灵活……但是你不能在你的字符串上获得100%的安全，你只能在运行时意识到它们。

到目前为止，我从未需要使用枚举。自从它们在1.5或tiger版本中被引入以来，我就一直在阅读有关它们的文章。他们从未真正为我解决过一个“问题”。对于那些使用它的人(我看到他们中的很多人这样做)，我确信它肯定有某种目的。只有我的2英镑。

除了前面提到的用例，我经常发现枚举对于实现策略模式很有用，遵循一些基本的面向对象原则:

将代码放在数据所在的位置(即在枚举本身中——或者通常在枚举常量中，这可能会覆盖方法)。 实现一个(或更多)接口，以便不将客户端代码绑定到枚举(它应该只提供一组默认实现)。

最简单的例子是一组Comparator实现:

enum StringComparator implements Comparator<String> {
    NATURAL {
        @Override
        public int compare(String s1, String s2) {
            return s1.compareTo(s2);
        }
    },
    REVERSE {
        @Override
        public int compare(String s1, String s2) {
            return NATURAL.compare(s2, s1);
        }
    },
    LENGTH {
        @Override
        public int compare(String s1, String s2) {
            return new Integer(s1.length()).compareTo(s2.length());
        }
    };
}

这种“模式”可以在更复杂的场景中使用，广泛使用枚举附带的所有优点:遍历实例，依赖于它们的隐式顺序，根据实例名称检索实例，为特定上下文提供正确实例的静态方法等等。你仍然把这些都隐藏在接口后面，这样你的代码就可以在不需要修改的情况下使用自定义实现，以防你想要一些“默认选项”中不可用的东西。

我曾看到这种方法成功地应用于时间粒度(每天、每周等)概念的建模，其中所有逻辑都封装在枚举中(为给定的时间范围选择正确的粒度，将特定行为绑定到每个粒度作为常量方法等)。而且，服务层所看到的粒度只是一个接口。