Pessoal, tenho um exercício pra fazer que consiste em informar o signo da pessoa baseado na data de nascimento.
Questionei sobre o tanto de ifs que daria isso (se nasceu entre tal e tal então é aries , se nasceu… Etc)
E o professor respondeu pra usar polimorfismo.
Já usei polimorfismo em outros cenários, mas não vejo como usar neste pra evitar os ifs… alguém da uma luz?
[RESOLVIDO]Polimorfismo x ifs
9 Respostas
Apenas informar com base na data? Apenas retornar o signo? Você não vai executar nada a partir do retorno dessa definição de signo?
Pergunto, porque se for apenas pra, com base em uma data retornar uma String do Signo, você usar um Enum e colocar nele todos os signos com 3 parâmetros data inicio do signo, data fim e um label de apresentação e você cria no seu Enum um getSigno com a data de nasicmento como parâmetro, varre o Enum e retorna o signo correto.
Como signo é algo que não vai crescer e nem diminuir com o tempo, você não precisa de toda uma estrutura polimórfica pra isso, ainda mais tendo em vista que não vai executar nada a partir desse signo.
Entendi, fica legal!
Mas, como o professor pediu pra usar polimorfismo, daí fiquei sem saber como fazer. Dá pra usar?
Cara, pra te ser honesto, eu posso estar cometendo um vacilo muito grande em não enxergar porque seu professor pediu pra usar polimorfismo nesse caso, mas eu simplesmente acho que seria um puta de um canhão de plasma pra matar uma formiga. Veja, você teria que criar uma classe Signo e mais 12 classes (uma para cada signo) com apenas um método getSigno retornando uma String.
Aí quando você passasse uma data de nascimento, talvez ainda tivesse que usar um factory pra poder retornar a instância correta do seu signo. Não me parece ser uma solução aprazível, ou seu professor realmente enxergou algo simples com polimorfismo que o jegue aqui realmente não está enxergando.
Talvez fizesse sentido usar em 1 cenário onde a partir do signo seu programa altera o comportamento do portador do signo, mas aí teria ainda que entender todo o cenário proposto pra poder dizer se ainda seria a melhor solução.
Veja, como disse anteriormente, seus signos não vão mudar nunca. A chance de surgir um novo signo ou um signo sumir é próximo de 0 e as chances de as datas de definição dos mesmos mudarem também são bem nulas, logo podemos dizer que signos são CONSTANTES.
E mesmo que fossem variáveis, uma mudança seria tão esporádica, que o custo de manutenção seria absurdamente baixo, ainda não valendo a pena criar uma penca de classes só pra isso.
Se algum colega que ler esse post e entendeu como usar polimorfismo pra resolver esse problema e puder me esclarecer, eu ficarei muito grato.
Adriano , exatamente como pensei. TB só enxerguei isso com 12 classes, um trabalho muito grande pra evitar 12 ifs .
Gostei da solução do é um, apesar do exércicio ser baseado em polimorfismo e interfaces. Vou postar o enunciado.
Provavelmente o que o seu professor quer é que você abstraia o conceito de horóscopo.
Além do horóscopo zodiacal, existem os horóscopos chinês ( intervalo de dia mês e ano ), japonês ( signos determinados pelo ano de nascimento ), indiano ( determinado por um intervalo de data e mês ) e, provavelmente, outros que não me recordo.
https://pt.wikipedia.org/wiki/Horóscopo_chinês
https://pt.wikipedia.org/wiki/Zodíaco
https://www.horoscopovirtual.com.br/artigos/horoscopo-indiano-signos-vedicos
Infelizmente isso ainda acontece muito no ensino, empurram o uso de recursos em situações desnecessárias. E pior, como consequencia o aluno leva isso pra vida profissional. Não é muito difícil ver o uso de interface sem a menor necessidade, assim como o trágico uso de herança, polimorfismo, etc.
Boa @rafaelbortoletto, não tinha enxergado essa possbilidade. Mas também isso teria que estar definido no escopo da pergunta, porém faz total sentido 
Obrigado a todos e desculpem pela demora. A única maneira que achei pra usar polimorfismo neste caso deixa tudo muito trabalhoso e realmente não compensa. Marquei o tópico como resolvido.
O mais importante é isso mesmo, não colocar recurso técnico na frente da necessidade. Infelizmente vai ver até pessoas experientes cometendo excesso de engenharia, burocratizando com uso de Interfaces sem necessidade, complicando a funcionalidade de negócio com polimorfismo, amarrações com herança, etc.