Se o atributo faz parte da invariante do objeto, sem problemas. Na pratica, vc decide o melhor momento, impede a criação do objeto ou da lança um erro na hora de utiliza-lo.
eu acho que faz sentido sim. Se o objeto for persistido, você já mata o problema na criação do objeto, que quando o objeto for persistido, não vai precisar de validação verificando se "description" está "preenchido.
Se o atributo faz parte da invariante do objeto, sem problemas. Na pratica, vc decide o melhor momento, impede a criação do objeto ou da lança um erro na hora de utiliza-lo.
É correto sim. O motivo é que implicitamente, o super() é chamado antes de qualquer coisa. Quando você compila o java coloca o super() na primeira linha do construtor que irá chamar o construtor da classe Object (se não for extends alguma coisa), mas você pode colocar tb, o efeito é o mesmo.
Assim, nas próximas linhas você pode chamar o this sem problema. Você também pode colocar o this() para referenciar o seu construtor sem argumento e esse construtor sem argumento também irá chamar o super().
eu acho que faz sentido sim. Se o objeto for persistido, você já mata o problema na criação do objeto, que quando o objeto for persistido, não vai precisar de validação verificando se "description" está "preenchido.
Se o atributo faz parte da invariante do objeto, sem problemas. Na pratica, vc decide o melhor momento, impede a criação do objeto ou da lança um erro na hora de utiliza-lo.
O grande problema com esse tipo de abordagem é quando se usa framework de persistencia. Ai precisamos utilizar POJO e nesse caso obrigatoriamente teremos que ter um construtor default assim a validação no construtor foi pro espaço.
Espalhar regras de validação também não é uma boa.
É correto sim. O motivo é que implicitamente, o super() é chamado antes de qualquer coisa. Quando você compila o java coloca o super() na primeira linha do construtor que irá chamar o construtor da classe Object (se não for extends alguma coisa), mas você pode colocar tb, o efeito é o mesmo.
Assim, nas próximas linhas você pode chamar o this sem problema. Você também pode colocar o this() para referenciar o seu construtor sem argumento e esse construtor sem argumento também irá chamar o super().
eu acho que faz sentido sim. Se o objeto for persistido, você já mata o problema na criação do objeto, que quando o objeto for persistido, não vai precisar de validação verificando se "description" está "preenchido.
Se o atributo faz parte da invariante do objeto, sem problemas. Na pratica, vc decide o melhor momento, impede a criação do objeto ou da lança um erro na hora de utiliza-lo.
Como quase tudo, depende da situação. É uma regra de negocio ou do objeto? A questão é que se eu preciso do objeto pronto para ser usado, eu tenho que impedir que ele seja criado sem um estado consistente. É uma regra da criação objeto.
As validações que fazemos normalmente levam em consideração o negocio, não pensamos muito nos objetos.
Eu não posso por exemplo criar um FileWriter(File f), se o file apontar p/ path inexistente, a exceção é lançada no construtor.
No caso de um POJO, sim não faz muito sentido, principalmente se ele esta sendo usado por um framework.
O grande problema com esse tipo de abordagem é quando se usa framework de persistencia. Ai precisamos utilizar POJO e nesse caso obrigatoriamente teremos que ter um construtor default assim a validação no construtor foi pro espaço.
Espalhar regras de validação também não é uma boa.
É correto sim. O motivo é que implicitamente, o super() é chamado antes de qualquer coisa. Quando você compila o java coloca o super() na primeira linha do construtor que irá chamar o construtor da classe Object (se não for extends alguma coisa), mas você pode colocar tb, o efeito é o mesmo.
Assim, nas próximas linhas você pode chamar o this sem problema. Você também pode colocar o this() para referenciar o seu construtor sem argumento e esse construtor sem argumento também irá chamar o super().
eu acho que faz sentido sim. Se o objeto for persistido, você já mata o problema na criação do objeto, que quando o objeto for persistido, não vai precisar de validação verificando se "description" está "preenchido.
Se o atributo faz parte da invariante do objeto, sem problemas. Na pratica, vc decide o melhor momento, impede a criação do objeto ou da lança um erro na hora de utiliza-lo.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
