Я использовал вложенные перечисления в тех редких случаях, когда я хотел применить соглашение об именовании значений перечисления, если добавление новых имен будет иметь значение для операций или других людей.Вот один пример:
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";
}
}
Я использую Enum, потому что хочу иметь возможность передавать общее «имя шаблона сообщения» в разных местах.Как видите, первая часть имени enum соответствует каталогу на сервере, а остальная часть имени относится к имени файла шаблона Velocity.Если коллеги-инженеры начали вводить новые константы, я бы хотел убедиться, что они были поданы под соответствующим «получателем», или если законно требуется создать нового получателя, что это сознательное усилие, и вы сообщитеоперации (создайте каталог в производственной среде, установите любые мониторинг / разрешения и т. д.).
Есть достойный аргумент, что если в какой-то момент ваш Enum станет слишком сложным, вы можете заменить его классом / классомиерархия в сочетании с гораздо более простым перечислением.Не уверен, где я рисую линию, но я полагаю, что вышеизложенное движется в этом направлении.