Resolvi postar aqui pois é um assunto relativamente simples, a que peço uma orientação. Estou desenvolvendo um projeto em que terei dois tipos de cliente, Pessoa Fisica e Pessoa Juridica. Da forma como o mesmo foi modelado, na base gravaríamos um campo para identificar cada um, com os valores “PF” ou “PJ”. Até aí tranquilo, hoje está tudo funcionando.
No objeto que abstrai o Cliente dentro do programa, há duas constantes:
public static final String PESSOA_FISICA = "PF";
public static final String PESSOA_JURIDICA = "PJ";
E todos os pontos onde isso é necessario ser tratado, sao usadas essas constantes. Nada anormal e tudo funciona.
Eu particularmente prefiro Enum a constantes em função da tipagem. Para esse caso, o Enum seria algo do tipo:
Use enum mesmo - você pode usar em switch, e em muitos lugares é possível tratá-los como se fossem inteiros (tradução: vão ser processados mais rapidamente).
Para obter uma instância da enum TipoCliente por nome, use:
Hum, não tinha visto que você queria achar o “PF”, não o “PESSOA_FISICA”. Eu fiz este exemplo aqui para inteiros (256, 720), troque a lógica para Strings (PF, PJ).
Sem contar que, em enums, pode-se adicionar alguma lógica na própria enum (coisa que, com constantes, por mais que se possa otimizar uma lógica usando mapas ou algo assim, ainda fica mais lento).
Obrigado. Não obstante as vantagens do Enum, é justamente essa lógica que eu não queria ter que fazer no Enum. Queria que o valueOf(String) resolvesse de alguma forma mágica e achasse o meu “PF” (que é o que vai ficar no banco e a partir desse valor vou criar o objeto). Mas ao menos no Enum só vai ser feito uma vez, enquanto com as constantes o codigo está cheio de ifs pra validar a String…
[quote=alias]Obrigado. Não obstante as vantagens do Enum, é justamente essa lógica que eu não queria ter que fazer no Enum. Queria que o valueOf(String) resolvesse de alguma forma mágica e achasse o meu “PF” (que é o que vai ficar no banco e a partir desse valor vou criar o objeto). Mas ao menos no Enum só vai ser feito uma vez, enquanto com as constantes o codigo está cheio de ifs pra validar a String…
Obrigado, pessoal.[/quote]
Mas a lógica são apenas 6 linhas na sua enum (mais umas chavinhas ), e é igual para todas as enums que você for criar. Validar uma string (cujo processamento é infinitamente mais lento) em todos os pontos de seu código é uma “b…”. Se não for PF ou PJ, o getInstance vai retornar null; poderia até lançar uma exceção sua, derivada de RuntimeException, por exemplo.
private static final Map<String, TipoCliente> value2enum = new HashMap<String, TipoCliente>();
static {
for (TipoCliente v : values()) {
value2enum.put (v.getValue(), v);
}
}
public static TipoCliente getInstance(int v) {
return value2enum.get (v);
}
[quote=asaudate]Sem contar que, em enums, pode-se adicionar alguma lógica na própria enum (coisa que, com constantes, por mais que se possa otimizar uma lógica usando mapas ou algo assim, ainda fica mais lento).
[]´s[/quote]
Sobre a lógica, se precisar ainda pode usar polimorfismo implementando interfaces.
Sim, já alterei para o Enum aqui e o que arranquei de if…rs. Já melhorou bastante a leitura.
Aproveitando o assunto:
Para retornar os meus “PF” e “PJ”, eu sobrescrevi o metodo toString(). Fiz isso pelo fato desse projeto utilizar JSF. Pelo que encontrei, na expression language, caso ocorra uma comparação usando o Enum, a interpretação da expressao vai invocar o toString() e depois comparar o valor. Isso procede? (ainda nao testei aqui…)
Assim ficou:
public enum TipoUsuario{
PESSOA_FISICA("PF"), PESSOA_JURIDICA("PJ");
private String value;
private TipoUsuario(String value){
this.value = value;
}
public static TipoUsuario create(String s){
TipoUsuario t = null;
if (s.equals("PF"))
t = PESSOA_FISICA;
else if (s.equals("PJ"))
t = PESSOA_JURIDICA;
return t;
}
@Override
public String toString() {
return value;
}
}
[quote=alias]Sim, já alterei para o Enum aqui e o que arranquei de if…rs. Já melhorou bastante a leitura.
Aproveitando o assunto:
Para retornar os meus “PF” e “PJ”, eu sobrescrevi o metodo toString(). Fiz isso pelo fato desse projeto utilizar JSF. Pelo que encontrei, na expression language, caso ocorra uma comparação usando o Enum, a interpretação da expressao vai invocar o toString() e depois comparar o valor. Isso procede? (ainda nao testei aqui…)
Assim ficou:
public enum TipoUsuario{
PESSOA_FISICA("PF"), PESSOA_JURIDICA("PJ");
private String value;
private TipoUsuario(String value){
this.value = value;
}
public static TipoUsuario create(String s){
TipoUsuario t = null;
if (s.equals("PF"))
t = PESSOA_FISICA;
else if (s.equals("PJ"))
t = PESSOA_JURIDICA;
return t;
}
@Override
public String toString() {
return value;
}
}
), e é igual para todas as enums que você for criar. Validar uma string (cujo processamento é infinitamente mais lento) em todos os pontos de seu código é uma “b…”. Se não for PF ou PJ, o getInstance vai retornar null; poderia até lançar uma exceção sua, derivada de RuntimeException, por exemplo.