Substituindo o método equals versus criando um novo método

Question

Sempre pensei que o método .equals() em java deveria ser substituído para se tornar específico para a classe que você criou.Em outras palavras, procurar a equivalência de duas instâncias diferentes em vez de duas referências à mesma instância.No entanto, encontrei outros programadores que parecem pensar que o comportamento padrão do objeto deveria ser deixado de lado e um novo método criado para testar a equivalência de dois objetos da mesma classe.

Quais são os argumentos a favor e contra a substituição do método equals?

Answer 1

A substituição do método equals é necessária se você deseja testar a equivalência em classes de biblioteca padrão (por exemplo, garantindo que um java.util.Set contenha elementos exclusivos ou usando objetos como chaves em objetos java.util.Map).

Observe que, se você substituir iguais, certifique-se de honrar o contrato da API conforme descrito na documentação.Por exemplo, certifique-se de também substituir Objeto.hashCode:

Se dois objetos forem iguais de acordo com o método igual (objeto), chamando o método HashCode em cada um dos dois objetos deverá produzir o mesmo resultado inteiro.

EDITAR:Não postei isso como uma resposta completa sobre o assunto, então repetirei a afirmação de Fredrik Kalseth de que substituir iguais funciona melhor para objetos imutáveis.Para citar a API para Mapa:

Observação:Muito cuidado deve ser exercido se os objetos mutáveis ​​forem usados ​​como teclas de mapa.O comportamento de um mapa não é especificado se o valor de um objeto for alterado de uma maneira que afeta as comparações iguais, enquanto o objeto é uma chave no mapa.

Answer 2

Eu recomendo fortemente pegar uma cópia do Effective Java e ler o item 7 obedecendo às instruções contrato igual.Você precisa ter cuidado se estiver substituindo equals para objetos mutáveis, pois muitas das coleções, como Maps e Sets, usam equals para determinar a equivalência, e a mutação de um objeto contido em uma coleção pode levar a resultados inesperados.Brian Goetz também tem um bom visão geral da implementação de equals e hashCode.

Answer 3

Você "nunca" deve substituir equals & getHashCode para objetos mutáveis ​​- isso vale para .net e Java.Se você fizer isso, e usar esse objeto como chave em f.ex um dicionário e então mudar esse objeto, você terá problemas porque o dicionário depende do código hash para encontrar o objeto.

Aqui está um bom artigo sobre o assunto: http://weblogs.asp.net/bleroy/archive/2004/12/15/316601.aspx

Answer 4

@David Schlosnagle menciona menciona Josh Bloch Java eficaz -- isto é um deve ler para qualquer desenvolvedor Java.

Há um problema relacionado:para objetos de valor imutável, você também deve considerar substituir compare_to.A redação padrão para se eles diferem está no API comparável:

Geralmente é o caso, mas não é estritamente necessário que (compare(x, y)==0) == (x.equals(y)).De um modo geral, qualquer comparador que viole esta condição deverá indicar claramente este facto.O idioma recomendado é "Nota:este comparador impõe ordenações que são inconsistentes com iguais."

Answer 5

O método Equals destina-se a comparar referências.Portanto, não deve ser substituído para alterar seu comportamento.

Você deve criar um novo método para testar a equivalência em diferentes instâncias, se necessário (ou usar o método CompareTo em algumas classes .NET)

Answer 6

Para ser honesto, em Java não há realmente um argumento contra a substituição é igual a.Se você precisar comparar instâncias quanto à igualdade, é isso que você faz.

Conforme mencionado acima, você precisa estar ciente do contrato com código hash, e, da mesma forma, tome cuidado com as pegadinhas ao redor Comparável interface - em quase todas as situações você deseja que o ordenação natural conforme definido por Comparable para ser consistente com iguais (Veja o GrandeDecimal documento da API para o exemplo do contador canônico)

Criar um novo método para decidir a igualdade, além de não funcionar com as classes da biblioteca existentes, vai um pouco contra a convenção Java.

Answer 7

Você só precisa substituir o equals() método se desejar um comportamento específico ao adicionar objetos a estruturas de dados classificadas (SortedSet etc.)

Ao fazer isso, você também deve substituir hashCode().

Ver aqui para uma explicação completa.