Contratos Nulos [Dúvida]

Oi,

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

Valeeuuuu Shoes!

Agora esclareceu minhas dúvidas . Pode ser que não havia prestado muito atenção no negócio. Mas enfim, parabéns pelo artigo lá bem interessante.

Se me permite, achei alguns erros nele, principalemente de palavras repitidas, e outras palavras perdidas no texto. :lol:

Abraço!

Alemd o meu conehcido problema na digitaçao, tem o copiar e colar maldito

Se ahcar algo grave, por favor me avise

Tenta o pdf que ele indica, houve uma tentativa de “refactoring” nele uhauhauhauhahua

Pessoal, desculpe mas to chegando agora neste tópico e gostaria de saber onde está este artigo do Shoes.

Algum link?

valeus!

olá,

http://www.fragmental.com.br/arquivos/contratosnulos.pdf

Nunca fui fã de DBC, não acho que traduza direito em código. Eiffel é uma prova disso, a linguagem é horrivel de usar.

Bom,

eu li o artigo e achei interessante, apesar de em alguns momentos o código poder ficar meio confuso dependendo do que for feito (lógico).

Então, a comparação de campos com null é uma boa saída pra vc?

Como vc propõe que seja feito o controle dos objetos?

Use o padrão null-object ou exceptional-case object.

Louds, voce poderia indicar material sobre esses padrões “null-object ou exceptional-case object”?

Muito interessante e prático o null-object, entretanto todos os exemplos que eu vi tinham algum tipo de singleton - alguma razão em especial ?

Agora, não encontrei, ainda que tenha pesquisado apenas alguns minutos, nada sobre o “exceptional-case object”, poderiam me dar mais detalhes?

Bom,

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.

O que acham disso?

Geralmente na classe. Uma classe é responsável por se manter em estado válido e lançar exceções caso este seja violado.

Qual a questão?

Google…
Você quis dizer…

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.

Pq “Infelizmente”?

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 ?

Não é uma implementação de DBC mas é uma forma de verificar contratos, creio (nunca usei).

Pq “Infelizmente”?

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 ?

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

pcalcado:

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.

Qual a questão?

Desculpem pelas pontuações

Queria saber se o hibernate validator seria um exemplo de “design by contract”?

mateusbrum:

Pq “Infelizmente”?

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 ?

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

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.

maurenginaldo:

pcalcado:

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.

Qual a questão?

Desculpem pelas pontuações

Queria saber se o hibernate validator seria um exemplo de “design by contract”?

Ele não é um exemplo por si só, mas é uma ferramenta que lhe ajuda para o design.

O pessoal do OVal tentou fazer algo assim com AOP: http://oval.sourceforge.net/userguide.html

Rubem Azenha:

O pessoal do OVal tentou fazer algo assim com AOP: http://oval.sourceforge.net/userguide.html

Hummm... bem legal.
Algumas anotações lembram as do hibernate validator.
Gostei muito da anotação para checagem do contrato baseado em uma inner static class.

@CheckWith(DayCheck.class)
  private int day;

  private static class DayCheck implements CheckWithCheck.SimpleCheck
  {
    public boolean isSatisfied(Object validatedObject, Object value)
    {
      try {
        GregorianCalendar cal = new GregorianCalendar();
        cal.setLenient(false);
        cal.set(GregorianCalendar.YEAR, ((DayEntity) validatedObject).year);
        cal.set(GregorianCalendar.MONTH, ((DayEntity) validatedObject).month - 1);
        cal.set(GregorianCalendar.DATE, ((DayEntity) validatedObject).day);
        cal.getTimeInMillis(); // may throw IllegalArgumentException return true;
      } catch (IllegalArgumentException e) {}
      return false;
    }
  }

Alguem está utilizando?