Uso (e abuso) do Enum

Programação Arquitetura
#1

Moçada,

Estou fazendo uma aplicação onde o Modelo tem muitas coisas fixas e discretas, o que é um uso bom para do enum. Envolve consulta de dados de estações hidrológicas, meteorológicas e etc.

Daí comecei a usar enums (muitos), criei um com as estaçoes, um para o tipo das estações, um para grupos de estações que o usuário vai visualizar em conjunto e agora mais um para o modo de operação do programa (pode ser simulação ou previsão).

No modelo uso um facade que o controlador acessa, mas deixei os enums publicos tb, pq facilita muito no controlador para fazer comparaçoes, armazenar o estado, ifs, cases, verificação estática e tal.

Minha dúvida é se estou abusando dos enums. No início tava usando eles até para aramazenas os dados. Mas agora só pra coisa dinâmica.

Segue abaixo a listagem do que tem as info de postos:

public enum Postos {
    MORSING_FLU("Morsing", "Q", 22324346, VAZAO_MODELO),
    MORSING_PLU("Morsing pluviômetro", "P Morsing", 22324346, PRECIPITACAO),
    MORSING_OBSERVADOR("Morsing Observador", "P Obs.", -1, PRECIPITACAO_OBSERVADOR),
    PIRAI("Barra do Piraí", "P Piraí", 22274347, PRECIPITACAO),
    SANTA_CECILIA("Santa Cecília", "P Sta Cec.", 22284351, PRECIPITACAO),
    PASSA_TRES("Passa Três", "P Passa 3", 22414400, PRECIPITACAO),
    BARRAGEM_SANTANA("Barragem Santana", "P Santana", 22314349, PRECIPITACAO),
    FAZ_NOVA_ESPERANCA("Faz. Nova Esp.", "Q Faz.", 22394357, VAZAO_MODELO),
    FAZ_NOVA_ESPERANCA_OBSERVADOR("Faz. Nova Esp. Observador", "P Obs.", -1, PRECIPITACAO_OBSERVADOR),
    FAZ_NOVA_ESPERANCA_PLU("Faz. Nova Esp. pluviômetro", "P Faz.", 22394357, PRECIPITACAO),
    TOCOS_PLU("Tocos pluviômetro", "P Tocos", 22444407, PRECIPITACAO),
    TOCOS_BARRAGEM("Barragem de Tocos", "Q barragem", 22454407, VAZAO_MODELO),  
    TOCOS_VERTEDOURO("Tocos Vertedouro", "Q ver.", 22454407, VAZAO),  
    TOCOS_OBSERVADOR("Tocos Observador", "P Obs.", -1, PRECIPITACAO_OBSERVADOR),
    LIDICE_FLU("Lídice linímetro", "Q Lídice", 22494411, VAZAO_MODELO),
    LIDICE_PLU("Lídice pluviômetro", "P Lídice", 22504411, PRECIPITACAO),
    LIDICE_OBSERVADOR("Lídice Observador", "P Obs.", -1, PRECIPITACAO_OBSERVADOR),
    VARZEA("Vázea", "Q Várzea", 22464405, VAZAO),
    ROSARIO("Rosário", "Q Rosário", 22474403, VAZAO),
    RIO_DO_BRACO("Rio do Braço", "P r. braço", 22474411, PRECIPITACAO),
    TOCOS_DESC_FUNDO("Tocos Desc. de Fundo", "Q fundo", 22444407, VAZAO);
        
    public final String nome;
    public final String nomeDisplay;
    public final int codigo;
    public final TipoPostos tipo;
                    
    Postos(String nome, String nomeDisplay, int codigo, TipoPostos tipo) {
        this.nome = nome;
        this.nomeDisplay = nomeDisplay;
        this.codigo = codigo;
        this.tipo = tipo;
    }
    
    
    public String toString() {
        return this.nome;
    }
    
    public static Postos getFromCodVazao(int cod) {
        for (Postos posto: Postos.values())
            if ((posto.tipo.equals(VAZAO) || 
                posto.tipo.equals(VAZAO_MODELO)) && posto.codigo==cod)
                return posto;
        throw new AssertionError("Pedindo Codigo de Vazao de estacao inexistente"); 
    }
    
    public static Postos getFromCodChuva(int cod) {
        for (Postos posto: Postos.values())
            if (posto.tipo.equals(PRECIPITACAO) && posto.codigo==cod)
                return posto;
        throw new AssertionError("Pedindo Codigo de Vazao de estacao inexistente"); 
    }        
}
#2

Porque não colocar isso num BD ou num arquivo de configuração?

#3

Cara… isso aí tá com cara de tabela… desse jeito, por exemplo, você tem muito mais esforço para garantir integridade referencial, por exemplo, e qualquer alteração nesses dados requer alteração da classe e recompilação do projeto. Pense melhor!

Abraço,

Armando

#4

Kra vc pode deixar menos confuso esses seus enuns.
Mais ou menos assim

public enum Estado{

  SP{
	int valor() {
		return 1;
	}
	String descricao() {
		return toString();
	}
},
MG{
	int valor() {
		return 2;
	}
	String descricao() {
		return toString();
	}
};

}

pode ate criar uma interface para deixar sempre como retorno de valor e descricao.
ex.

public interface GenericEnum {

public String getDescricao();

public int getValor();

}

public enum Estado{

  SP{
	int valor() {
		return 1;
	}
	String descricao() {
		return toString();
	}
},
MG{
	int valor() {
		return 2;
	}
	String descricao() {
		return toString();
	}
};
    
    abstract int valor();
abstract String descricao();

    // Esses kras sao implemtados da interface..
    public int getValor(){
	return valor();
}

public String getDescricao() {
	return descricao();
}

}

[]'s

#5

Obrigado pelas respostas pessoal. Acho legal discutir sobre arquitetura, todo mundo ganha e é mais interessante que tópicos do tipo “Por que tá dando erro”. :smiley:

Na verdade esse dado tem no banco (até uso o código do enum para fazer as consultas). Mas não é exatamente a estrutura que preciso. E como já existem outras aplicações usando o bd, não posso mudar a tabela. Fora o trabalho de mapear e tal… Um jeito seria criar uma view ou coisa do gênero.

Olhando bem, esse enum praticemente não tem lógica, então poderia virar um arquivo texto tb. Ganharia flexibilidade, mas perderia a verificação na compilação e daria mais trabalho.

O argumento de manter a intergridade relacional é forte mesmo. Acho que é o que vai me fazer por a mão na massa…

Mas essa é a única enum desse jeito, as outras são do tipo:

Para essas acho que enum ainda é uma ótima alternativa.

Quanto à outra forma de escrever o enum (proposta pelo foliveira81), fazendo cada item extender os métodos, não acho que fique tão mais claro. Depois que vc pega o jeito dá no mesmo. E gera mais código…

#6

Yeap. :wink:

#7