De fato, é mais interessante ter um supertipo Membro com os métodos save, restart , etc. e implementar as regras específicias em cada sub-tipo do que ficar testando um campo do tipo Enum para escolher a regra, seria esse o caso ?
colored
Então cara. p falar a verdade o negocio ta tão sei lá… que tipo o q tem d diferente é so o cargo que pega pelo enum…
Minha dúvida é. por q tipo do jeito q estaria sendo feito todos objetos estariam na mesma tabela… e caso eu precisasse de todos ao mesmo tempo eu conseguiria…
Só que por interface e cada tipo de membro separado por classe Não certo??
rmendes08
colored:
Então cara. p falar a verdade o negocio ta tão sei lá… que tipo o q tem d diferente é so o cargo que pega pelo enum…
Minha dúvida é. por q tipo do jeito q estaria sendo feito todos objetos estariam na mesma tabela… e caso eu precisasse de todos ao mesmo tempo eu conseguiria…
Só que por interface e cada tipo de membro separado por classe Não certo??
Depende, se estivermos falando de JPA/Hibernate é possível realizar consultas polimórficas, dependendo de como você faz o mapeamento. Mas é aquela velha história, cada caso é um “causo”. Se a única diferença entre os tipos de membros é o valor do campo TIPO, então nesse caso não vale a pena usar polimorfismo. Ou seja, se o tipo de Membro não define regras diferentes você não precisa generalizar/especializar suas classes, crie métodos get/set e seja feliz.
colored
Certo. Tipo com Herança se Membro fosse uma classe abstrata e Diretor por exemplo herdasse dela.
Eu Conseguiria buscar os objetos de Diretor pela classe de Membro.
Com a Interface seria do mesmo jeito?
---- e Voltando ao Assunto cara, no caso Diretor é uma classe que irá ter outros comportamentos do demais pelo menos agora no inicio ela também será utilizada em outro modulo, então tem algumas outras responsabilidades…
Tipo Ela ja existe, mas no caso também deveria ser um membro entendeu?
