Correta implementação de Object#equals e Object#hashCode e ajuda de IDE's

This message was edited 2 times. Last update was at 13/12/2011 01:47:53

De acordo com a documentação oficial, equals indica que um objeto é igual a outro e ainda define.

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Bem como hashCode deve retornar um valor hash para dado um objeto e com a seguinte afirmação.

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

Entendo que, dado um objeto que possua sua lógica de identidade no hashCode o equals só passa mesmo a verificar se o outro a comparar não é nulo e pertence a mesma classe.

A interpretação está correta?
Se sim, porque os IDE's tanto o Eclipse quanto o Netbeans implementam os snipets codes para equals e hashCode replicando a lógica do hashCode dentro do equals e vice-versa? Ou estou falando bobeira?

This message was edited 4 times. Last update was at 13/12/2011 06:27:11

Nem sempre.

O método hashCode diz que dois objetos iguais devem ter hashes iguais. Porém, ele não proíbe objetos diferentes de terem hashes iguais.
Portanto, o hashCode não pode ser usado como substituto de um id (pelo menos, não em todos os casos).

Veja como exemplo a classe String e alguns dos seus hashcodes repetidos:
2464: "N.", "Ll", "MM"
110990: "pig", "peã", "discóbolo"
3143404: "fixa", "inflamabilidade"
97793703: "fungo", "fujão"
103156083: "longo", "lojão"

De fato, essa é uma implementação pouco eficiente, mas perfeitamente válida, de hashcode:

Um bom hashcode terá uma chance muito pequena de se repetir, mas a chance existe.
Um hashcode com força de criptografia ainda terá como requisito fornecer uma mudança grande e imprevisível, mesmo que o valor mude pouco.

By the way. As IDEs implementam o hashcode de acordo com o algorítmo proposto por Joshua Block, no Effetive Java.

A descrição do algorítmo fiz nesse post:
http://www.guj.com.br/java/52485-hashcode-duvida#276120

Você, a princípio, nem sequer precisa usar todos os campos para o hashcode.
Num objeto que só tem id, vc poderia usar o próprio id e talvez algum outro campo para os objetos que não receberam id ainda.

E claro, você poderia forçar a condição que você comentou: Colocar a lógica de identidade no hashcode. E aí sua implementação poderia ser a que você propôs.
É só importante entender que essa não é a regra geral.

Virtual Machine Man Membro desde: 29/08/2006 21:50:17 Mensagens: 523 Offline

ViniGodoy wrote:Nem sempre.
É só importante entender que essa não é a regra geral.

Entendido perfeitamente, faz total sentido (agora que você explicou é claro)

Obrigado!

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