Está tudo bem ir contra o uso de maiúsculas e minúsculas para enumerações para tornar sua representação de String mais simples?

Várias vezes eu já vi pessoas usarem maiúsculas ou minúsculas para constantes enum, por exemplo:

enum Color {
  red,
  yellow,
  green;
}

Isso simplifica e facilita o trabalho com a forma de sequência, se você quiser throw new IllegalStateException("Light should not be " + color + "."), por exemplo.

Isso parece mais aceitável se o enum for private, mas ainda não gosto. Eu sei que posso criar um construtor de enum com um campo String e substituir toString para retornar esse nome, assim:

enum Color {
  RED("red"),
  YELLOW("yellow"),
  GREEN("green");

  private final String name;

  private Color(String name) { 
    this.name = name 
  }

  @Override public String toString() {
    return name; 
  }
}

Mas veja quanto tempo isso é. É chato continuar fazendo se você tem um monte de pequenas enumerações que deseja manter simples. Tudo bem usar apenas formatos de caso não convencionais aqui?

A resposta curta é, obviamente, se você deseja interromper as convenções de nomenclatura para o que são essencialmente constantes ... Citando o JLS :

Nomes constantes

Os nomes das constantes nos tipos de interface devem ser e as variáveis ​​finais dos tipos de classe convencionalmente podem ser uma sequência de uma ou mais palavras, acrônimos ou abreviações, todas em maiúsculas, com componentes separados por caracteres sublinhados "_". Os nomes constantes devem ser descritivos e não abreviados desnecessariamente. Convencionalmente, eles podem ser qualquer parte apropriada do discurso.

A resposta longa, com relação ao uso de toString(), é definitivamente esse o método a ser substituído, se você quiser uma representação mais legível dos enumvalores. Citando Object.toString()(ênfase minha):

Retorna uma representação de string do objeto. Em geral, o toStringmétodo retorna uma string que "representa textualmente" esse objeto . O resultado deve ser uma representação concisa, mas informativa, fácil para uma pessoa ler . É recomendável que todas as subclasses substituam esse método.

Agora, não sei por que algumas das respostas se voltaram para falar sobre a conversão enumsde um lado para outro com Stringvalores, mas também darei minha opinião aqui. Tal serialização de enumvalores pode ser facilmente tomado cuidado usando o name()ou ordinal()métodos. Ambos são finale, portanto, você pode ter certeza dos valores retornados, desde que os nomes ou o posicionamento dos valores não sejam alterados . Para mim, isso é um marcador suficientemente claro.

O que recordo do exposto é: hoje, você pode querer descrever YELLOWsimplesmente como "amarelo". Amanhã, você pode descrevê-lo como "Pantone Minion Yellow" . Estas descrições devem ser devolvidos a partir chamando toString(), e eu não esperaria tanto name()ou ordinal()à mudança. Se o fizer, é algo que preciso resolver na minha base de código ou na minha equipe e se tornará uma questão maior do que apenas um enumestilo de nomeação .

Concluindo, se tudo o que você pretende fazer é registrar uma representação mais legível dos seus enumvalores, ainda assim sugerirei seguir as convenções e depois substituí-las toString(). Se você também pretende serializá-los em um arquivo de dados ou em outros destinos que não sejam Java, você ainda tem os métodos name()e ordinal()para fazer backup de você, portanto não há necessidade de se preocupar em substituir toString().

Não modifique ENUMisso é apenas mau cheiro de código. Deixe um enum ser um enum e uma string ser uma string.

Em vez disso, use um conversor CamelCase para valores de sequência.

throw new IllegalStateException("Light should not be " + CamelCase(color) + ".");

Existem muitas bibliotecas de código aberto que já resolvem esse problema para Java.

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/CaseFormat.html

Ao enviar enumerações entre meu código Java e um banco de dados ou aplicativo cliente, geralmente acabo lendo e gravando os valores de enumeração como seqüências de caracteres. toString()é chamado implicitamente ao concatenar seqüências de caracteres. Substituir toString () em algumas enumerações significava que, às vezes, eu podia

"<input type='checkbox' value='" + MY_CONST1 + "'>"

e às vezes eu tinha que lembrar de ligar

"<input type='checkbox' value='" + MY_CONST1.name() + "'>"

o que levou a erros, então eu não faço mais isso. Na verdade, eu não substituo nenhum método no Enum, porque se você aplicá-lo a um código de cliente suficiente, acabará quebrando as expectativas de alguém.

Faça o seu próprio nome novo método, como public String text()ou toEnglish()ou qualquer outra coisa.

Aqui está uma pequena função auxiliar que pode economizar algumas digitações se você tiver muitas enumerações como as acima:

public static String ucFirstLowerRest(String s) {
    if ( (s == null) || (s.length() < 1) ) {
        return s;
    } else if (s.length() == 1) {
        return s.toUpperCase();
    } else {
        return s.substring(0, 1).toUpperCase() + s.substring(1).toLowerCase();
    }
}

É sempre fácil chamar .toUpperCase () ou .toLowerCase (), mas voltar a maiúsculas e minúsculas pode ser complicado. Considere a cor "bleu de France". A França está sempre em maiúscula, portanto, você pode adicionar um método textLower () à sua enumeração, se você o encontrar. Quando você usa esse texto no início de uma frase, no meio de uma frase e em um título, pode ver como um único toString()método ficará aquém. E isso nem toca em caracteres que são ilegais nos identificadores Java, ou que são difíceis de digitar porque não são representados em teclados padrão ou caracteres que não possuem maiúsculas (Kanji, etc.).

enum Color {
  BLEU_DE_FRANCE {
    @Override public String textTc() { return "Bleu De France"; }
    @Override public String textLc() { return "bleu de France"; }
  }
  CAFE_NOIR {
    @Override public String textTc() { return "Café Noir"; }
  }
  RED,
  YELLOW,
  GREEN;

  // The text in title case
  private final String textTc;

  private Color() { 
    textTc = ucFirstLowerRest(this.toString());
  }

  // Title case
  public String textTc() { return textTc; }

  // For the middle of a sentence
  public String textLc() { return textTc().toLowerCase(); }

  // For the start of a sentence
  public String textUcFirst() {
    String lc = textLc();
    return lc.substring(0, 1).toUpperCase() + lc.substring(1);
  }
}

Não é tão difícil usá-los corretamente:

IllegalStateException(color1.textUcFirst() + " clashes horribly with " +
                      color2.textLc() + "!")

Espero que isso também demonstre por que o uso de valores de enumeração de maiúsculas e minúsculas também o decepcionará. Um último motivo para manter as letras maiúsculas com sublinhados constantes enum é que isso segue o Princípio da menor surpresa. As pessoas esperam isso; portanto, se você fizer algo diferente, sempre terá que se explicar ou lidar com pessoas que abusam do seu código.

Se houver a menor chance de que essas representações de seqüência de caracteres possam ser armazenadas em locais como bancos de dados ou arquivos de texto, vinculá-las às constantes reais da enumeração se tornará altamente problemática se você precisar refatorar sua enumeração.

E se um dia você decidir mudar o nome Color.Whitepara Color.TitaniumWhitequando houver arquivos de dados lá fora, que contêm "White"?

Além disso, quando você começa a converter constantes enum em strings, o próximo passo adiante é gerar strings para o usuário ver, e o problema aqui é, como eu já sei, que a sintaxe do java não permitir espaços dentro dos identificadores. (Você nunca terá Color.Titanium White.) Portanto, como você provavelmente precisará de um mecanismo apropriado para gerar nomes de enumeração para mostrar ao usuário, é melhor evitar complicar desnecessariamente sua enumeração.

Dito isto, é claro que você pode seguir em frente e fazer o que estava pensando em fazer, e depois refatorar sua enumeração mais tarde, para passar nomes ao construtor, quando (e se) tiver problemas.

Você pode raspar algumas linhas do seu enum-com-construtor declarando o namecampo public finale perdendo o getter. (Que amor é esse que os programadores java têm em relação aos getters?)

Indiscutivelmente, seguir a convenção de nomenclatura UPPERCASE viola DRY . (E YAGNI ). por exemplo, no exemplo de código 2: "RED" e "red" são repetidos.

Então, você segue a convenção oficial ou segue DRY? Sua chamada.

No meu código, seguirei DRY. No entanto, colocarei um comentário na classe Enum, dizendo "nem todas maiúsculas porque (explicação aqui)"