+questão do simulado da kathy

No simulado tem a seguinte questão q tbm n concordo com a reposta

which of the following will fulfill the equals() and hashCode() contracts for this class? (choose all that apply).

A - return (( SortOf)o).bal == this.bal

B - return (( SortOf)o).code.length() = this.code.length()

C - return (( SortOf)o).code.length() * (( SortOf)o).bal == this.code.length() * this.bal;

D - return (( SortOf)o).code.length() * (( SortOf)o).bal * (( SortOf)o).rate == this.code.length() * this.bal * this.rate;

RESPOSTA: C e D.

mas p mim aresposta é só a C pq se colocar pos seguintes valores quebro o contrato de equals e hashCode, onde se equals == true hashCode tem o mesmo valor.

code.length() bal rate equals hashCode
3 * 3 * 2 = 18 9
2 * 3 * 3 = 18 6

Alguém ai ver outra coisa q n tou conseguindo enxergar, p dar a resposta do simulado ?

o contrato diz que para a forma eficiente sue hascode deve retornar igual qdo seu equals for igual.. mais se o codigo hashing for diferente nao tem problema qdo seu equals é true.. vc vai senti a dificuldade usar conjuntos.

lembre-se isso nao é regra de equals() true e hashcode ser ==.

é apenas uma sugestão que normalmente todo mundo usa.. pq qdo for usar conjuntos, array vc encontrar o objeto.

Leia novamente com mais carinho essa parte do livro da kathy e observe as entre-linhas

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

LPJava wrote:o contrato diz que para a forma eficiente sue hascode deve retornar igual qdo seu equals for igual.. mais se o codigo hashing for diferente nao tem problema qdo seu equals é true.. vc vai senti a dificuldade usar conjuntos.

lembre-se isso nao é regra de equals() true e hashcode ser ==.

Não é uma regra no sentido que o java não exige isso (apenas algumas partes do java exigem, como Set), mas é uma regra no sentido que a certificação irá testar se vc conhece a regra e sabe aplicar a regra (leia-se implementar equals e hashcode de forma coerente) para aplicar em Set.
Enfim, é uma não-regra que é uma regra de fato.
A duvida do LPJava procede, porque segundo a tal regra hashcode tem que ser igual quando equals é igual. Tal como o LPJava já falou, com aquele código da opção D é possivel ter hash diferente quando equals é igual. Se a pergunta não estivesse sendo feita no contexto da regra do hashcode-equals então A e B tb estariam certas, já que se não ha nenhuma relação, qualquer coisa é aceitável.

Poderiamos pensar que existe algum erro de tipografia e que * é na realidade outro operador, mas não consigo encontrar nenhum operador em que a opção D seja coerente com a regra.

assim falei.. para ele nao ver como regra.. mais no exame ele pode avaliar das duas formas.. principalmente qdo envolver conjuntos.. mais a essencia é o q vc falou equal true, hashcode true tb.... no meu exame eu fui avaliado de das duas formas.. eficiente e menos eficiente :d

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

LPJava wrote:assim falei.. para ele nao ver como regra.. mais no exame ele pode avaliar das duas formas.. principalmente qdo envolver conjuntos.. mais a essencia é o q vc falou equal true, hashcode true tb....

Eficiência é outro ponto que não têm diretamente a ver. O hashcode pode seguir a regra e não ser eficiente. Por exemplo

É extremamente rápido, é coerente com a regra , mas não é eficiente.

no meu exame eu fui avaliado de das duas formas.. eficiente e menos eficiente :d

Não será que foi avaliado pela mesma coisa ? Se vc sabe quando se aplica e sabe quando não se aplica, então vc sabe o que é...

sergio e vc entendeu que eu disse o q? pq eu falei voltado para o exame... o q ele pode ser avaliado.. na hora e nao acha que um codigo ineficiente está errado..

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