No simulado tem a seguinte questão q tbm n concordo com a reposta
class SortOf{
String name;
int bal;
String code;
short rate;
public int hashCode(){
return code.length() * bal
}
public boolean equals(Object o){
//insert code here
}
}
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()
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.
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
[quote=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 ==.
[/quote]
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
[quote=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…
[/quote]
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…
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)