Ola a todos, tenho uma dúvida sobre a validação do objeto sobre seus estados. Um objeto deve ser responsável pela consistência de seus atributos lançando exceções quando algum dado está inconsistente certo? Mas o que acontece na maioria das aplicações WEB que vejo é que na verdade quem faz a verificação dos atributos do objeto são os frameworks e não os próprios objetos, é correto isto, isso não tiraria o conceito principal de que o objeto deve ser responsável pela consistência de seus atributos?
Ex: Tenho uma classe cliente com um atributo CPF, ao invés de escrever um método CPF, e chamá-lo dentro do setCpf, o que geralemente fazem é deixar o framework Web tratar essa validação no Controller, antes de ser invocada no model. Ou criar uma classe com várias metodos estáticos tipo Tools.validaCPF, embora eu use isso tbm, gostaria de saber se tem outras alternativas?? Se é correto este tipo de abordagem ? O que é mais OO?
As pessoas tentem a não ser muito ortodoxas nestas técnicas de validação.
Alguns fazem a validação no próprio view, outras no controller, outras no model.
As que fazem validação no controller e no view fazer por questões de eficiência, as que fazem no model fazem por questões de elegância e portabilidade.
Eu particularmente utilizo validações no model. As vezes no view ou no controller quando eu não quero muito overead no sistema.
Acredito que deve-se ser bem flexível de acordo com o projeto. Utiliza-se muito o bom senso de cada desenvolvedor pra resolver este tipo de questão.
Interessante. Eu faço a validacao no model também. Ao meu ver, quando os dados serão sempre validados, o mais correto seria fazer a validacao no set. (minha opiniao)
Agora veja, (risos)
É muito complicado ter uma disciplina na Universidade onde é abordado 3 camadas (MVC), onde o professor fala que é errado ter algo alem de this.atributo = parametro em um set.
Sugeri exatamente isso: “Mas e a validacao dos dados, eu acho interessante colocar no set. bla bla bla”
Resposta do prof: "É um erro! NUNCA faça assim bla bla bla… "
Não me dá argumentos que me convenca, apenas o titulo de PhD… (que nao me convence)
Ele é que corrige a prova, eu faço da forma que ele quer, mas não deixo de usar a minha abordagem em meus projetos. Alias, nao ouvi dizer que essa abordagem é ERRADA.
[quote=renan_]Interessante. Eu faço a validacao no model também. Ao meu ver, quando os dados serão sempre validados, o mais correto seria fazer a validacao no set. (minha opiniao)
Agora veja, (risos)
É muito complicado ter uma disciplina na Universidade onde é abordado 3 camadas (MVC), onde o professor fala que é errado ter algo alem de this.atributo = parametro em um set.
Sugeri exatamente isso: “Mas e a validacao dos dados, eu acho interessante colocar no set. bla bla bla”
Resposta do prof: "É um erro! NUNCA faça assim bla bla bla… "
Não me dá argumentos que me convenca, apenas o titulo de PhD… (que nao me convence)
Ele é que corrige a prova, eu faço da forma que ele quer, mas não deixo de usar a minha abordagem em meus projetos. Alias, nao ouvi dizer que essa abordagem é ERRADA.
Alguem poderia me esclarecer?
Obrigado[/quote]
Olá Renan concordo plenamente com você pergunte seu professor então se você precisasse validar um CPF, de um objeto cliente onde esta validação estaria se tivesse que ser validado no model.
Eu acho certo a validação ser no Model, ou seja o objeto eh que vai ser responsável por seus estados, ele deve ainda lançar uma exception quando algum dado estiver incompleto;
Bem isso eh a minha opinião , vamos esperar alguem com mais experiência responder.
Bom, acho que o que o método faz em si seria mais uma questão de contrato, de você colocar na documentação o que está fazendo. Isso porque na sua aplicação, você poderia controlar a inserção de um CPF, não permitindo que um valor null fosse, setado. Já outra pessoa poderia permitir que o CPF fosse setado null. Então teríamos um sério problema. Acho que por isso eles dizem pra não fazer validação nesses métodos.
Pensando no que o g4j disse num mesmo sistema seria no mínimo inviável uma pessoa permitir null e outra não, com que critério isso funcionaria?, mas eu estava com dúvida de que deixar o framework fazer isso era correto e não fugia da definição OO de que o objeto tem que ser responsável pelos seus estados.
Parece que sim eh que eh muito utilizado hj.
Como assim? Num mesmo sistema seria permitido null e não null?
Isso não é problema. Se quer que o cpf seja null é só não usar o setter, não? Se quer usar o cpf, é obrigatório que seja válido.
validações que podem implicar no levantamento de exceções deviam ser tratadas no model sim no meu ponto de vista até por questão de reaproveitamento e coesão, toda vez que você reutilizar o model não vai ter que se preucupar em validar/tratar os dados para ele funcionar, porem outros tipos de validações como tamanho/mascara acho melhor externalizar até porque pode variar dependendo da regra.
Agora eh quanto a abordagem de criar uma classe Tools.metodos() estaticos, e invocar estes metodos no model para validar atributos podem assim ser aproveitas em varios projetos;
Via de regra, quando o objeto vai ter seu estado modificado, ele próprio deve checar se esse estado será válido ou não. Isso inclui qualquer tipo de validação sobre os dados pertencentes ao próprio.
Olá Emerson, mas eh correto criar uma classe Tools com metodos estaticos e invocar estes no model para checar se seus atributos eh valido, lançando exceções quando nao forem?
Não acho que seja interessante criar uma classe com metodos estáticos.
Em situações onde a mesma validação se repete pelo sistema, você pode criar um tipo (i.e. classe), que valida seu próprio estado, e usa-lo onde quiser. Um exemplo disso seria o próprio CPF que você mencionou. Se para seu sistema fizer sentido, você pode ter uma classe CPF representando um tipo e dentro dela você terá a validação do que é considerado um CPF valido para seu sistema. Mas isso só deve ser feito se essa regra for a mesma para todo sistema (que é o que eu acho que você está tentando fazer com a classe auxiliar cheia de métodos estáticos). Caso contrário, o melhor mesmo é fazer essa validação em cada objeto que contém esses atributos.
Não acho que seja interessante criar uma classe com metodos estáticos.
Em situações onde a mesma validação se repete pelo sistema, você pode criar um tipo (i.e. classe), que valida seu próprio estado, e usa-lo onde quiser. Um exemplo disso seria o próprio CPF que você mencionou. Se para seu sistema fizer sentido, você pode ter uma classe CPF representando um tipo e dentro dela você terá a validação do que é considerado um CPF valido para seu sistema. Mas isso só deve ser feito se essa regra for a mesma para todo sistema (que é o que eu acho que você está tentando fazer com a classe auxiliar cheia de métodos estáticos). Caso contrário, o melhor mesmo é fazer essa validação em cada objeto que contém esses atributos.
[/quote]
Olá Emerson obrigado pelas respostas eu falei da classe Tools com métodos estáticos, porque eu posso reaproveitar elas em vários projetos, além de validação ela tem outrs metodos auxiliares como conversão de certos tipos um pouco mais complexas além de validações como por exemplo metodo para verficar se um CPF é valido, se um CNPJ é valido
Neste caso fica entao eu deveria criar uma classe CPF e outra CNPJ cada uma contendo sua validação??
[quote=danielbussade] Olá Emerson obrigado pelas respostas eu falei da classe Tools com métodos estáticos, porque eu posso reaproveitar elas em vários projetos, além de validação ela tem outrs metodos auxiliares como conversão de certos tipos um pouco mais complexas além de validações como por exemplo metodo para verficar se um CPF é valido, se um CNPJ é valido
Neste caso fica entao eu deveria criar uma classe CPF e outra CNPJ cada uma contendo sua validação??[/quote]
Assim como library básica do Java nos fornece alguns objetos que usamos (e.g. java.util.Date), você pode criar os seus próprios objetos para esse fim e distribuir em um JAR para ser usado por outras aplicações da sua empresa. Mas provavelmente esse JAR só vai servir para sua empresa, ou até mesmo apenas alguns sistemas dessa.
Voce pode sim, criar classes CPF e CNPJ, contendo não somente as validações, mas também esses métodos auxiliares que você mencionou.
Só lembre-se de uma coisa: Se você for usar isso em apenas um lugar, não vale a pena criar, melhor refatorar depois se for o caso.
[quote=danielbussade] Ola a todos, tenho uma dúvida sobre a validação do objeto sobre seus estados. Um objeto deve ser responsável pela consistência de seus atributos lançando exceções quando algum dado está inconsistente certo? Mas o que acontece na maioria das aplicações WEB que vejo é que na verdade quem faz a verificação dos atributos do objeto são os frameworks e não os próprios objetos, é correto isto, isso não tiraria o conceito principal de que o objeto deve ser responsável pela consistência de seus atributos?
[/quote]
A palavra “validação” é ambígua.
Uma coisa é o objeto verificar a consistencia do seu estado. Outra coisa é o sistema verificar o constrangimento do objeto.
Por exemplo, um objeto Calendar consiste o seu estado de forma a nunca indica uma data que não é possivel.
Mas lá porque a data é possível ( 1/1/3009) não significa que o sistema possa aceitá-la como valor para um campo de um entidade. ( por exemplo 1/1/3009 é inválido para uma data de nascimento de um sistema correndo em 1/1/2008 - supondo um universo sem viagens no tempo, claro (Principio de Occam))
São duas ações de verificação diferentes.
Normalmente os objetos das aplicações são simples conjuntos de propriedades (PropertyBag) cujos campos são tipos simples (Date, integer, String… ) ou VO especializados ( money, pex) Estes objetos simples já fazem uma consistência, normalmente Integer não aceita “sa” como valor. Portanto, o PropertyBag é consistente se os seus campos são consistentes.
Mas isso não significa nada. O PropertyBag tem que passar pela verificação de constrangimento que a aplicação estipula.
E por isso sempre temos um passo de “validação” que é a verificação do constrangimento (não da consistência)
O objeto A tem um campo CPF. Ele é do tipo String.
Uma String aceita qualquer coisa. Logo, é automáticamente consistente.
Contudo, a aplicação terá que verificar o constrangimento do CPF verificar certas regras. Ou seja, temos que verificar se o CPF é válido ( não o String CPF, mas a informação CPF).
O objeto A tem um campo CPF. Ele é do tipo CPFType.
Uma CPFType não aceita qualquer coisa. Ele só aceita 9 digitos. Isso é consistente.
Contudo não verifica nenhuma regra 123456789 é um CPF consistente, embora não válido.
Então o sistema aceita um CPF consistente ( sempre é assim porque o objeto que contém a informação já é consistente por natureza, entende?) mas ele tem que verificar regras de constrangimento do CPF.
Essas regras não são da responsabildiade do numero do cPF e sim de uma instituição prórpria. i.e. outro objeto.
Esse outro objeto (padrão Specification) estipula a regra.
Entenda que a regra básica é fazer um modulo 11 para saber se o CPF está digitado corretamente. Isto não lhe diz nada sobre se o CPF existe realmente. Parai sso vc precisa de outro objeto que comunica com algum orgão do governo e informa se o CPF existe.
Melhor, se ele existe e é da pessoa que tem o nome X (onde X é outro campo de A)
Verificação de Consistencia de Estado e Verificação de Constangimento são duas coisas diferentes.
[quote=sergiotaborda][quote=danielbussade] Ola a todos, tenho uma dúvida sobre a validação do objeto sobre seus estados. Um objeto deve ser responsável pela consistência de seus atributos lançando exceções quando algum dado está inconsistente certo? Mas o que acontece na maioria das aplicações WEB que vejo é que na verdade quem faz a verificação dos atributos do objeto são os frameworks e não os próprios objetos, é correto isto, isso não tiraria o conceito principal de que o objeto deve ser responsável pela consistência de seus atributos?
[/quote]
A palavra “validação” é ambígua.
Uma coisa é o objeto verificar a consistencia do seu estado. Outra coisa é o sistema verificar o constrangimento do objeto.
Por exemplo, um objeto Calendar consiste o seu estado de forma a nunca indica uma data que não é possivel.
Mas lá porque a data é possível ( 1/1/3009) não significa que o sistema possa aceitá-la como valor para um campo de um entidade. ( por exemplo 1/1/3009 é inválido para uma data de nascimento de um sistema correndo em 1/1/2008 - supondo um universo sem viagens no tempo, claro (Principio de Occam))
São duas ações de verificação diferentes.
Normalmente os objetos das aplicações são simples conjuntos de propriedades (PropertyBag) cujos campos são tipos simples (Date, integer, String… ) ou VO especializados ( money, pex) Estes objetos simples já fazem uma consistência, normalmente Integer não aceita “sa” como valor. Portanto, o PropertyBag é consistente se os seus campos são consistentes.
Mas isso não significa nada. O PropertyBag tem que passar pela verificação de constrangimento que a aplicação estipula.
E por isso sempre temos um passo de “validação” que é a verificação do constrangimento (não da consistência)
O objeto A tem um campo CPF. Ele é do tipo String.
Uma String aceita qualquer coisa. Logo, é automáticamente consistente.
Contudo, a aplicação terá que verificar o constrangimento do CPF verificar certas regras. Ou seja, temos que verificar se o CPF é válido ( não o String CPF, mas a informação CPF).
O objeto A tem um campo CPF. Ele é do tipo CPFType.
Uma CPFType não aceita qualquer coisa. Ele só aceita 9 digitos. Isso é consistente.
Contudo não verifica nenhuma regra 123456789 é um CPF consistente, embora não válido.
Então o sistema aceita um CPF consistente ( sempre é assim porque o objeto que contém a informação já é consistente por natureza, entende?) mas ele tem que verificar regras de constrangimento do CPF.
Essas regras não são da responsabildiade do numero do cPF e sim de uma instituição prórpria. i.e. outro objeto.
Esse outro objeto (padrão Specification) estipula a regra.
Entenda que a regra básica é fazer um modulo 11 para saber se o CPF está digitado corretamente. Isto não lhe diz nada sobre se o CPF existe realmente. Parai sso vc precisa de outro objeto que comunica com algum orgão do governo e informa se o CPF existe.
Melhor, se ele existe e é da pessoa que tem o nome X (onde X é outro campo de A)
Verificação de Consistencia de Estado e Verificação de Constangimento são duas coisas diferentes.[/quote]
Resumindo:
Você quer dizer que colocar um atributo CPF como sendo String na sua entidade é algo “errado” (de acordo com as afirmações acima), pois qualquer String que for passada para esse objeto deve ser considerada como válida dentro do sistema?
Errado é o que você considerar que seja errado. O objeto CPF é seu.
Apesar disso o senso comum é seguir o padrão definido pelo governo, 9 dígitos que devem ser validados com 2 dígitos verificadores segundo uma regra.
Além da consistência, outra vantagem e que o próprio objeto pode fornecer serviços que o envolvem para resto do sistema. Um deles é a formatação.
O mesmo p/ CNPJs, inscrições estaduais, e outros documentos.
Mas como o Sergio falou, uma coisa é consistência de estado, outra são as regras/restrições impostas pelo sistema, um CPF pode ser válido ou não, independente de se você aceitar somente CPFs que já estejam cadastrados na base.
