Por que .compareTo () está em uma interface enquanto .equals () está em uma classe em Java?

Quero saber por que o .compareTo()está na Comparableinterface enquanto um método como .equalsestá na Objectclasse. Para mim, parece arbitrário o motivo de um método como esse .compareTo()ainda não estar na Objectclasse.

Para usar .compareTo(), você implementa a Comparableinterface e implementa o .compareTo()método para seus propósitos. Para o .equals()método, você simplesmente substitui o método em sua classe, pois todas as classes são herdadas da Objectclasse.

Minha pergunta é por que um método é semelhante a .compareTo()uma interface que você implementa, e não a uma classe Object? Da mesma forma, por que o .equals()método da classe Objecte não em alguma interface deve ser implementado?

Nem todos os objetos podem ser comparados, mas todos os objetos podem ser verificados quanto à igualdade. Se nada mais, é possível ver se existem dois objetos no mesmo local na memória (igualdade de referência).

O que isso significa compareTo()em dois Threadobjetos? Como um segmento é "maior que" outro? Como você compara dois ArrayList<T>s?

O Objectcontrato se aplica a todas as classes Java. Se nem uma classe puder ser comparada a outras instâncias de sua própria classe, Objectnão será possível exigir que ela faça parte da interface.

Joshua Bloch usa as palavras-chave "ordenação natural" ao explicar por que uma classe pode querer implementar Comparable. Nem toda classe tem uma ordem natural, como mencionei nos meus exemplos acima, portanto nem toda classe deve implementar Comparablenem deve Objectter o compareTométodo.

... o compareTométodo não está declarado em Object. ... É de caráter semelhante ao método de Objects equals, exceto pelo fato de permitir comparações de ordem, além de comparações simples de igualdade, e é genérico. Ao implementar Comparable, uma classe indica que suas instâncias têm uma ordem natural .

_{^{Java eficaz, segunda edição : Joshua Bloch. Item 12, Página 62. As elipses removem referências a outros capítulos e exemplos de código.}}

Para os casos onde não querem impor uma ordenação em um não- Comparableclasse que não tem uma ordem natural, você sempre pode fornecer uma Comparatorinstância para ajudar a resolver isso.

O JLS §4.3.2 define o classobjeto da seguinte maneira:

4.3.2 O objeto de classe

A classe Objecté uma superclasse (§8.1.4) de todas as outras classes.

Todos os tipos de classe e matriz herdam (§8.4.8) os métodos de classe Object, resumidos da seguinte forma:

• O método cloneé usado para criar uma duplicata de um objeto.

• O método equalsdefine uma noção de igualdade de objeto, que se baseia em comparação de valor, não de referência.

• O método finalizeé executado imediatamente antes de um objeto ser destruído (§12.6).

• O método getClassretorna o objeto Class que representa a classe do objeto.

• Existe um Classobjeto para cada tipo de referência. Ele pode ser usado, por exemplo, para descobrir o nome completo de uma classe, seus membros, sua superclasse imediata e quaisquer interfaces que ela implemente.

  O tipo de expressão de invocação de método getClassé Class<? extends |T|>onde Té pesquisada a classe ou interface (§15.12.1) getClass.

  Um método de classe declarado synchronized(§8.4.3.6) é sincronizado no monitor associado ao objeto Class da classe.

• O método hashCodeé muito útil, juntamente com o método igual, em hashtables como java.util.Hashmap.

• Os métodos wait, notifye notifyAllsão utilizados em linhas de programação utilizando simultâneas (§17.2).

• O método toStringretorna uma representação String do objeto.

Então, é por isso que equalsestá dentro, Objectmas compareToestá em uma interface separada. Eu especularia que eles queriam manter Objecto mínimo possível. Eles provavelmente imaginaram que quase todos Objects precisariam equalse hashCode(que é realmente apenas uma forma de teste de igualdade), mas nem todos os objetos precisariam ter um conceito de ordenação , para o que compareToé usado.

Além da excelente resposta do Snowman, lembre-se de que essa Comparableinterface é genérica há muito tempo. Um tipo não implementa compareTo(object), implementa compareTo(T)onde Té seu próprio tipo. Isso não pode ser implementado object, pois objectnão conhece a classe que será derivada dela.

objectpoderia ter definido um compareTo(object)método, mas isso teria permitido não apenas o que Snowman aponta, uma comparação entre dois ArrayList<T>s ou entre dois Threads, mas também uma comparação entre um ArrayList<T>e a Thread. Isso é ainda mais absurdo.

Suponha que eu tenha duas referências a objetos: X identifica uma instância de Stringretenção do conteúdo "George"; Y identifica a instância de Pointretenção das coordenadas [12,34]. Considere as duas perguntas a seguir:

• X e Y identificam objetos equivalentes?

• X deve classificar antes, depois ou equivalente a Y?

O fato de X e Y identificarem instâncias de tipos não relacionados não apresenta nenhum problema ao considerar a primeira pergunta. Objetos só podem ser considerados equivalentes se seus tipos compartilharem uma base comum que os define como equivalentes; uma vez que Stringe Pointnão possui essa base (seu único tipo de base comum considera todos os objetos distintos como não equivalentes), a resposta é simplesmente "não".

O fato de os tipos não serem relacionados, no entanto, coloca um enorme problema em relação à segunda questão. Alguns tipos de definir relações de ordenação entre os seus casos, e algumas relações de ordenação pode mesmo estender-se por vários tipos [por exemplo, seria possível para BigIntegere BigDecimaldefinir métodos de comparação que permitiriam instâncias de qualquer tipo para ser classificado em relação a instâncias do outro], mas em geral, não é possível tomar duas instâncias arbitrárias e perguntar "Deveria X ordenar antes, depois ou equivalente a Y" e derivar uma ordem total. Seria possível perguntar "Deve X ordenar antes, depois, equivalente ou sem classificação em relação a Y" se os objetos precisarem relatar uma ordem consistente, mas não um totalum, mas a maioria dos algoritmos de classificação exige pedidos totais. Assim, mesmo que todos os objetos pudessem implementar um compareTométodo se "sem classificação" fosse um retorno válido, esse método não seria útil o suficiente para justificar sua existência.