Estive lendo um artigo do shoes, sobre contratos Nulos. Achei bem legal ele e a discussão que trouxe.
Porém me restou uma dúvida quanto a “solução” proposta. Talvéz alguém que tenha lido ou mesmo o philip possa me esclarecer.
Bom no começo do artigo ele trata do problema levantado pelo Todd Huss em algum post. E fala de uma solução que tods fazem que é:
public metodo(String a)
{
if(a==null)
throw new MinhaException("argumento não pode ser nulo");
}
O que seria igual que se o método lançasse uma NPE.
Depois ele discorre sobre várias outras soluções propostas, e no final trata do Design by Contract. E sua solução é implementar o pré-contrato e pós-contrato em métodos específicos, que mudam o estado do objeto.
Bom, segundo os seus exemplos ele acaba verificando os atributos da classe e parametros dos métodos e lança exceptions se elas não cumprirem o contrato, e a implementação continua igual a acima citada (código acima). Gostaria de saber no exemplo citado acima por ele, como fazer a implementação? (Verificar parâmetros null) Continuo verificando igual os objetos passados para o método e lanço exception? Eu entendi o resto do artigo e sobre os contratos e tudo mais. Só que ficou essa dúvida, pois a solução citada (código acima) foi meio criticada segundo o artigo e depois acabou em algo muito parecido (igual?!).
A questao levantada no artigo eh que nao se deve simplesmente conferir se um valor eh nulo ou nao. Nao adianta checar valores nulos apenas, deve-se obedecer o contrato.
Quando alguem diz que NPE eh erro de programador,e sta certo, mas o que eh preciso de definir sao contratos de utilizacao dos objetos.
O que ficar definido como pre-condiçao contratual deve ser obedecido. Se isso implica em “parametro X nao pode ser nulo”, isso deve ser obedecido por quem o chama.
Como escrevi la, infelizmente Java nao da suporte a DbC como fazem outras linguagens mais puristas, entao voce vait er que escolher entre checar “manualmente” as pre-condiçoes ou definir que se um objeto chamador nao obedecer o contrato, voce nao pode obedecer a pos condiçao.
A primeira opçao eh indicada nos metodos que voce expoe como interface a usuarios ou outros sistemas, como actions num MVC qualquer. Voce nao sabe se quem esta invocando a operaçao vai cumprir o contrato, nao eh voce quem escreve este codigo.
A segunda alternativa eh a mais utilizada. Se voce nao recebeu sua pre-condiçao correta, nao garante sua pos condiçao, entao uma NPE eh possivel, mas o erro nao eh (neste caso) do metodo chamado, eh de quem o chamou, que nao obedeceu a pre-condiçao.
Mesmo linguagens como Eiffel, com aplo suporte a pre e pos condiçoes, definem que se pode “ligar” ou “desligar” a chacagem de contrato para performance. Geralmente se liga esta checagem enquanto se esta desenvolvendo e em debug.
Resumindo: Nao adianta checar NPEs, o que se deve fazer eh estipular e obedecer contratos
já faz um tempo que esse post foi aberto, mas é um assunto muito interessante.
:arrow: Se eu for estabelecer contratos para um Entity Bean, onde ficariam a checagem dos atributos: na própria classe ou em outra classe?
:arrow: Outra questão: O hibernate validator seria uma implementação de “design by contract”, onde colocamos uma anotação por exemplo @Lenght(min=5,max=10) como definição da invariante. Porém a pré e pós condição é tratada por ele ao persistir o objeto.
[quote] Outra questão: O hibernate validator seria uma implementação de “design by contract”?( onde colocamos uma anotação por exemplo @Lenght(min=5,max=10) como definição da invariante.)
Porém b[/b] a pré e pós condição é tratada por ele ao persistir o objeto. [/quote]
Se o contrato, deferido pela anotação, esta na classe que deve ter seu estado policiado e regido por este contrato, qual o problema dele estar em metadados ?
Se o contrato, deferido pela anotação, esta na classe que deve ter seu estado policiado e regido por este contrato, qual o problema dele estar em metadados ? [/quote]
Porque a validação do contrato é verificada na persistência, talvez tarde demais.
Nota: nunca usei validators, só quis enfatizar o que entendi da pergunta anterior, não sei também se a validação só ocorre nesse nível
[quote=pcalcado][quote=maurenginaldo]
:arrow: Outra questão: O hibernate validator seria uma implementação de “design by contract”, onde colocamos uma anotação por exemplo @Lenght(min=5,max=10) como definição da invariante. Porém a pré e pós condição é tratada por ele ao persistir o objeto.
[/quote]
Qual a questão?
[/quote]
Desculpem pelas pontuações
Queria saber se o hibernate validator seria um exemplo de “design by contract”?
Se o contrato, deferido pela anotação, esta na classe que deve ter seu estado policiado e regido por este contrato, qual o problema dele estar em metadados ? [/quote]
Porque a validação do contrato é verificada na persistência, talvez tarde demais.
Nota: nunca usei validators, só quis enfatizar o que entendi da pergunta anterior, não sei também se a validação só ocorre nesse nível[/quote]
Com hibernate validator a validação é realizada no momento da persistencia mas também pode ser realizada quando você quiser.
Você pode invocar o hibernate validator dentro dos metodos do seus objetos para garantir as invariantes sem maiores problemas.
