Com getters e setters da mesma forma que está o construtor.
Sabendo que o projeto está sendo trabalhado no modelo MVC, qual seria a melhor forma de proibir que o valor salario seja negativo? No construtor e setters ou em algum outro arquivo?
E se for aqui na classe da entidade, existe alguma forma de eu lançar uma exceção que destrua o objeto?
Não acho interessante você aplicar esse tipo de validação no construtor ou nos setters/getters, crie um método que verifica se o valor está negativo, se sim, lance uma exceção.
[]'s
D
Deleu
E o que acontece com o objeto construído?
getAdicted
A partir do momento que você instâncía um objeto é reservada memória. Se houver a validação antes da atribuição ao atributo salário, o mesmo não chegará a ser inicializado com o respectivo valor negativo.
[]'s
D
Deleu
Então a melhor ideia seria ter uma classe separada que valide as informações e eu só crio um novo objeto da classe Funcionário se todas as validações retornarem sucesso.
Seria isso?
getAdicted
Deleu:
Então a melhor ideia seria ter uma classe separada que valide as informações e eu só crio um novo objeto da classe Funcionário se todas as validações retornarem sucesso.
Seria isso?
Não, apenas crie um método na sua classe Funcionário. Eu não acho interessante existir uma classe Funcionário e uma classe ValidaQuesitosFuncionários. Mantenha as regras de negócios pertinentes à classe Funcionário na própria classe Funcionário.
[]'s
gomesrod
getAdicted:
Não acho interessante você aplicar esse tipo de validação no construtor ou nos setters/getters, crie um método que verifica se o valor está negativo, se sim, lance uma exceção.
[]'s
Apenas uma pequena correção: é uma boa prática colocar validações nos setters e construtores, assim garante-se que o estado do objeto jamais estará inconsistente.
Mas nada impede de ter essa condição em algum outro lugar, de forma explícita. Por exemplo, em um javascript de validação de formulário, ou na validação de parâmetros de entrada de um serviço, etc.
Dessa forma a lógica da validação fica mais clara e está em pontos onde é mais fácil gerar mensagens amigáveis aos usuários.
getAdicted
gomesrod:
getAdicted:
Não acho interessante você aplicar esse tipo de validação no construtor ou nos setters/getters, crie um método que verifica se o valor está negativo, se sim, lance uma exceção.
[]'s
Apenas uma pequena correção: é uma boa prática colocar validações nos setters e construtores, assim garante-se que o estado do objeto jamais estará inconsistente.
Mas nada impede de ter essa condição em algum outro lugar, de forma explícita. Por exemplo, em um javascript de validação de formulário, ou na validação de parâmetros de entrada de um serviço, etc.
Dessa forma a lógica da validação fica mais clara e está em pontos onde é mais fácil gerar mensagens amigáveis aos usuários.
Olá gomesrod,
Obrigado pela correção, pensando dessa maneira, sim, eu concordo. Dessa forma cada acesso ao atributo já viria com a validação, interessante! :thumbup:
[]'s
gomesrod
Pois é, teoricamente deveríamos sempre fazer isso, de forma a evitar a todo custo que os objetos fiquem com estado inválido (afinal, com a validação fora não há como garantir que ela será chamada).
Mas na prática dificilmente o fazemos, geralmente a validação fica só em um método fora do objeto mesmo. E nos acostumamos tanto com isso que a validação no setter chega a parecer esquisita…
getAdicted
gomesrod:
Pois é, teoricamente deveríamos sempre fazer isso, de forma a evitar a todo custo que os objetos fiquem com estado inválido (afinal, com a validação fora não há como garantir que ela será chamada).
Mas na prática dificilmente o fazemos, geralmente a validação fica só em um método fora do objeto mesmo. E nos acostumamos tanto com isso que a validação no setter chega a parecer esquisita…
Concordo, estamos tão condicionados a não vermos isso que quando vemos, machuca os olhos
