嵌套枚举-为什么使用它？

Question

我见过在枚举内声明枚举的构造。这是做什么用的？

Answer 1

Java 中的枚举无法扩展，因此如果您想在一个地方整理强相关的枚举，您可以使用这些嵌套的枚举结构。例如：

public enum DepartmentsAndFaculties
{
   UN (null, "UN", "University"),
   EF (UN,   "EF", "Engineering Faculty"),
   CS (EF,   "CS", "Computer Science & Engineering"),
   EE (EF,   "EE", "Electrical Engineering");

   private final DepartmentsAndFaculties parent;
   private final String code, title;

   DepartmentsAndFaculties(DepartmentsAndFaculties parent, String code, String title)
   {
       this.parent = parent;
       this.code   = code;
       this.title  = title;
   }

   public DepartmentsAndFaculties getParent()
   {
       return parent;
   }

   public String getCode()
   {
       return code;
   }

   public String getTitle()
   {
       return title;
   }
}

这里，内部枚举由 {parent enum, code, title} 组合组成。用法示例：

 DepartmentsAndFaculties cs = DepartmentsAndFaculties.CS;
 cs.getTitle();

在构造分层实体/枚举时，您可以看到嵌套枚举的强大功能。

Answer 2

您可能将枚举视为内部类型。当外部类型是类或接口时，最常见的是这种情况，但我认为没有任何理由不能使用枚举作为外部来完成此操作。

内部类型部分与代码组织有关。当您有几种相关的类型时，它们有助于避免创建一堆单独的文件。有时它可以使类型名称更直观。例如，请参见 Map 类及其内部 Entry 类。大多数对 Entry 的外部引用都会使用 Map.Entry 格式，这种格式非常可读。

使用内部类型的另一个原因是，如果外部类型是类或枚举，则内部类型可以是非公共的。这对于隐藏作为外部类型的实现细节的类型很有用。

Answer 3

我在极少数情况下使用了嵌套枚举，如果添加新名称会对操作或其他人产生影响，我想对枚举值强制执行命名约定。这是一个示例：

public enum MessageTemplateName {

    account_verify,
    vendor_job_request,
    account_job_confirmed,
    vendor_job_confirmed,
    account_friend_request,
    account_job_accepted,
    vendor_job_accepted_by_other;

    /** Make sure you tell operations if you're adding a new recipient */
    private enum Recipient { account, vendor }

    private Recipient recipient;
    private String messageName;

    MessageTemplateName () {
        final int firstUnderscore = name().indexOf('_');
        recipient = Recipient.valueOf(name().substring(0, firstUnderscore));
        messageName = name().substring(firstUnderscore+1);
    }

    public String getTemplateUrl (String baseUrl) {
        if (!baseUrl.endsWith("/")) baseUrl += "/";
        return baseUrl + recipient.name() + "/" + messageName + ".vm";
    }

}

我使用枚举是因为我希望能够在不同的地方传递通用的“消息模板名称”。正如您所看到的，枚举名称的第一部分对应于服务器上的目录，名称的其余部分指的是 Velocity 模板文件名。如果其他工程师开始引入新的常量，我想确保它们被归档在适当的“收件人”下，或者如果合法地需要创建新的收件人，那么这是有意识地这样做，并且您会通知操作（在生产中创建目录、放置任何监视/权限等）。

有一个不错的论点是，如果在某个时候你的枚举变得太复杂，你可以用类/类层次结构加上更简单的枚举来替换它。不确定我的界限在哪里，但我想上面的内容正在朝那个方向发展。