Ambas as switch
afirmações e o polimorfismo têm seu uso. Observe que também existe uma terceira opção (em idiomas que suportam ponteiros de função / lambdas e funções de ordem superior): mapeando os identificadores em questão para funções de manipulador. Está disponível em, por exemplo, C, que não é uma linguagem OO, e C #, que é *, mas não (ainda) em Java, que também é OO *.
Em algumas linguagens processuais (sem polimorfismo nem funções de ordem superior) switch
/ if-else
declarações eram a única maneira de resolver uma classe de problemas. Muitos desenvolvedores, acostumados a esse modo de pensar, continuaram a usar switch
mesmo nas linguagens OO, onde o polimorfismo costuma ser uma solução melhor. É por isso que é frequentemente recomendado evitar / refatorar switch
declarações em favor do polimorfismo.
De qualquer forma, a melhor solução depende sempre do caso. A questão é: qual opção oferece um código mais limpo, conciso e mais sustentável a longo prazo?
As instruções de troca geralmente podem se tornar pesadas, tendo dezenas de casos, dificultando a manutenção. Como você precisa mantê-los em uma única função, essa função pode crescer muito. Se for esse o caso, considere refatorar para uma solução baseada em mapa e / ou polimórfica.
Se o mesmo switch
começar a aparecer em vários lugares, o polimorfismo é provavelmente a melhor opção para unificar todos esses casos e simplificar o código. Especialmente se se espera que mais casos sejam adicionados no futuro; quanto mais lugares você precisar atualizar a cada vez, mais possibilidades de erros. No entanto, geralmente os manipuladores de casos individuais são tão simples, ou existem muitos deles, ou são tão inter-relacionados, que refatorá-los para uma hierarquia de classes polimórfica completa é um exagero ou resulta em muitos códigos duplicados e / ou emaranhados, difícil manter a hierarquia de classes. Nesse caso, pode ser mais simples usar funções / lambdas (se o seu idioma permitir).
No entanto, se você tiver um switch
em um único local, com apenas alguns casos fazendo algo simples, pode ser a melhor solução para deixá-lo como está.
* Eu uso o termo "OO" aqui vagamente; Não estou interessado em debates conceituais sobre o que é OO "real" ou "puro".