+questão do simulado da kathy

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

LPJava:

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

LPJava:

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

public final int hashCode (){
   return 13;
}

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

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 é… 8)

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…