Refactoring: Substituindo Condicional por Polimorfismo usando enum!
Esse refactoring é muito interessante quando feito sobre condicionais que lidam com parâmetros que podem mudar com freqüência. Esses parâmetros podem ser tipos de relatórios, comandos utilizados para invocar métodos remotamente, estados de uma máquina entre outros.
O objetivo da utilização do polimorfismo é justamente dar flexibilidade e permitir que o sistema evolua (mude) sem precisar adicionar novos blocos de else if no código toda vez que um novo parâmetro for adicionado, alterado ou removido! Sendo assim, não precisa sair alterando todos os blocos if else do sistema, apenas os pontos mais suscetíveis a mudança e que a flexibilidade fará com que as operações de manutenção possam ser mais agradáveis.
Nosso foco são estruturas que dependem de parâmetros para executar ações como por exemplo gerar um extrato. Os extratos podem ser de vários tipos: Semanais, quinzenais, mensais, completos e tantos outros quanto os clientes necessitarem ao longo da vida útil do sistema.
Abaixo, a classe responsável por gerar um extrato utilizando um tipo passado como parâmetro:
Estruturas como essa além de serem procedurais, diminuem a performance do sistema e com o tempo aumentam os custos de manutenção do projeto, contribuindo para um código ilegível (imagine com 50 tipos de extrato) e desmotivante.
Uma forma interessante de resolver o problema é mapear os estados em uma enum e utilizá-la para mapear os estados polimorficamente:
E finalmente podemos refatorar o método condicional da classe que gera extratos para delegar a geração de extratos para as subclasses:
Lembrando que essa é uma forma simplificada da utilização do padrão Strategy, no entanto evitamos a criação excessiva de artefatos (cada estratégia numa subclassse) e utilizamos a enum para fazer esse trabalho.