Acima estou demostrando apenas um caso de Herença.
Agora vem a dúvida:
public class Atendimento{
// faço assim o mapeamento
Conveniado profissionalSaude;//pode ser medido ou dentista - POLIMORFISMO
String tipoProfissional; //define se é medico ou dentista
//ou assim
Medico medido;//nesse caso quando for medico o dentista fica null, ou vice-versa.
Dentista dentista;
}
Qual das maneiras está correto? posso aplicar polimorfismo para persistir os dados?
Lembrando que um ATENDIMENTO, deve ser por um MEDICO ou um DENTISTA.
Obrigado.
public enum TipoProfissional {MEDICO, DENTISTA}; //define se é medico ou dentista
public class Atendimento{
private Medico medico;
private Dentista dentista;
TipoProfissional tipoProfissional;
}
dessa forma você poderia validar o tipo dentro do enum, que seria uma constante que vc define, estaria persistido também.
é mais padronizado do que na string
Com o uso do enum vc poderia dar essa persistencia a mais para não deixar instanciar os dois ao mesmo tempo
public class Atendimento{
// faço assim o mapeamento
Conveniado profissionalSaude;//pode ser medido ou dentista - POLIMORFISMO
String tipoProfissional; //define se é medico ou dentista
//ou assim
Medico medido;//nesse caso quando for medico o dentista fica null, ou vice-versa.
Dentista dentista;
}
Qual das maneiras está correto? posso aplicar polimorfismo para persistir os dados?
Lembrando que um ATENDIMENTO, deve ser por um MEDICO ou um DENTISTA.
Obrigado.
[/quote]
Eu faria assim:
public enum TipoProfissional {MEDICO, DENTISTA}; //define se é medico ou dentista
public class Atendimento{
private Medico medico;
private Dentista dentista;
TipoProfissional tipoProfissional;
}
dessa forma você poderia validar o tipo dentro do enum, que seria uma constante que vc define, estaria persistido também.
é mais padronizado do que na string
Com o uso do enum vc poderia dar essa persistencia a mais para não deixar instanciar os dois ao mesmo tempo
[/quote]Só coloque o TipoProfissional tipoProfissional; como private. :lol: :lol: :lol:
o “compilador” vai aceitar isso, mas nos sabemos que o tipoprofissonal é um objeto de médico e não um objeto de dentista…
e o problema só vai ocorrer em tempo de execução
outra questão, é a performance de efetuar todas as vezes um typecast.
Quando você tem algo que na verdade é um papel (“role”) a parte de herança é sempre um pouco mais difícil, e nem sempre muito adequada.
Se não me engano, em Portugal há poucos dentistas porque um dentista tem de ser um médico também - quando aqui no Brasil você pode ter pessoas que são só dentistas e pessoas que podem ser dentistas e médicos.
Vocês estão modelando as profissões como sendo mutuamente excludentes (não se pode ser ao mesmo tempo um dentista e um médico).
Mas aí entra no caso de programar para interfaces e não implementações.
A partir do momento que sua classe precisa de um Conveniado, você não deveria se importar se é um Medico ou um Dentista.
Você deveria usar apenas os métodos de Conveniado quando trabalhar com Atendimento.
Pense num List por exemplo.
Quantas vezes já sentiu necessidade de usar um método específico de um ArrayList ou de um LinkedList ?
No primeiro caso citado nada garante que a String/Enum que aponta o tipo esteja sincronizada com tipo em si de conveniado.
No segundo caso, você pode até garantir que só um objeto não seja nulo por você, mas aumenta a complexidade do código.
(Sem falar no número de atributos crescendo a cada implementação).
No exemplo que você deu, com o tipo ficaria assim:
Faz todo o sentido,
para que essa implementação fique mais correta e bem definida, seria interessante fazer como o array list faz com a list…
usando generics e interfaces, que é o mais seguro de se fazer, é que ele estava falando entre o polimorfismo e usar dois objetos, ao meu ver entre os dois eu usaria dois objetos, um null e outro não, de modo que evitaria typecast’s toda vez…