Contratos Nulos [Dúvida]

Olá galerinha.

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 é:

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?!).

Agradeço quem puder me esclarecer isso.

Abraços!

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.

Abraço!

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

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

Se ahcar algo grave, por favor me avise

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

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.

louds wrote: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.

JavaBaby Membro desde: 23/02/2005 10:58:35 Mensagens: 84 Offline

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

louds wrote:Use o padrão 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.

Se eu for estabelecer contratos para um Entity Bean, onde ficariam a checagem dos atributos: na própria classe ou em outra classe?

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?

maurenginaldo wrote:
Se eu for estabelecer contratos para um Entity Bean, onde ficariam a checagem dos atributos: na própria classe ou em outra classe?

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

maurenginaldo wrote:
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?

JavaBaby Membro desde: 21/01/2007 22:55:29 Mensagens: 84 Offline

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 (infelizmente) a pré e pós condição é tratada por ele ao persistir o objeto.

Notícias, artigos e o maior fórum brasileiro sobre Java