Pourquoi .compareTo () dans une interface alors que .equals () est dans une classe en Java?

Je veux savoir pourquoi .compareTo()est dans l' Comparableinterface alors qu'une méthode comme .equalsest dans la Objectclasse. Pour moi, il semble arbitraire pourquoi une méthode comme .compareTo()n'est pas Objectdéjà dans la classe.

Pour l'utiliser .compareTo(), vous implémentez l' Comparableinterface et implémentez la .compareTo()méthode à vos fins. Pour la .equals()méthode, vous remplacez simplement la méthode dans votre classe, car toutes les classes héritent de la Objectclasse.

Ma question est pourquoi une méthode est-elle comme .compareTo()dans une interface que vous implémentez plutôt que dans une classe comme Object? De même, pourquoi la .equals()méthode dans la classe Objectet non dans une interface doit-elle être implémentée?

Tous les objets ne peuvent pas être comparés, mais tous les objets peuvent être vérifiés pour leur égalité. Si rien d'autre, on peut voir si deux objets existent au même endroit en mémoire (égalité de référence).

Qu'est-ce que cela signifie pour compareTo()deux Threadobjets? Comment un fil est-il «supérieur à» un autre? Comment comparez-vous deux ArrayList<T>s?

Le Objectcontrat s'applique à toutes les classes Java. Si même une classe ne peut pas être comparée à d'autres instances de sa propre classe, elle Objectne peut pas exiger qu'elle fasse partie de l'interface.

Joshua Bloch utilise les mots clés "ordre naturel" pour expliquer pourquoi une classe pourrait vouloir implémenter Comparable. Toutes les classes n'ont pas un ordre naturel comme je l'ai mentionné dans mes exemples ci-dessus, donc toutes les classes ne doivent Comparablepas implémenter ni Objectavoir la compareTométhode.

... la compareTométhode n'est pas déclarée dans Object. ... Son caractère est similaire à celui de Objectla equalsméthode, sauf qu'il permet des comparaisons d'ordres en plus des comparaisons d'égalité simples, et il est générique. En implémentant Comparable, une classe indique que ses instances ont un ordre naturel .

_{^{Java efficace, deuxième édition : Joshua Bloch. Point 12, page 62. Les points de suspension suppriment les références à d'autres chapitres et exemples de code.}}

Pour les cas où vous ne voulez imposer un ordre sur une non Comparableclasse qui ne dispose pas d' un ordre naturel, vous pouvez toujours fournir un Comparatorexemple pour aider les trier.

Le JLS §4.3.2 définit l' classobjet de la manière suivante:

4.3.2. L'objet de classe

La classe Objectest une superclasse (§8.1.4) de toutes les autres classes.

Tous les types de classe et de tableau héritent (§8.4.8) des méthodes de classe Object, qui se résument comme suit:

• La méthode cloneest utilisée pour créer un doublon d'un objet.

• La méthode equalsdéfinit une notion d'égalité d'objet, qui est basée sur la comparaison de la valeur et non de la référence.

• La méthode finalizeest exécutée juste avant la destruction d'un objet (§12.6).

• La méthode getClassrenvoie l'objet Class qui représente la classe de l'objet.

• Un Classobjet existe pour chaque type de référence. Il peut être utilisé, par exemple, pour découvrir le nom complet d'une classe, ses membres, sa superclasse immédiate et toutes les interfaces qu'elle implémente.

  Le type d'une expression d'appel de méthode getClassest Class<? extends |T|>où Test la classe ou l'interface recherchée (§15.12.1) getClass.

  Une méthode de classe déclarée synchronized(§8.4.3.6) se synchronise sur le moniteur associé à l'objet Class de la classe.

• La méthode hashCodeest très utile, avec la méthode égale, dans des tables de hachage telles que java.util.Hashmap.

• Les méthodes wait, notifyet notifyAllsont utilisées dans la programmation simultanée à l'aide de threads (§17.2).

• La méthode toStringrenvoie une représentation String de l'objet.

C'est pourquoi equalsc'est dans Objectmais compareTodans une interface séparée. Je suppose qu'ils voulaient garder Objectle minimum possible. Ils ont probablement pensé que presque tous Objects auraient besoin equalset hashCode(ce qui n'est vraiment qu'une forme de test d'égalité), mais tous les objets n'auraient pas besoin d'avoir un concept de classement , ce qui compareToest utilisé.

En plus de l'excellente réponse de Snowman, rappelez-vous qu'il s'agit d' Comparableune interface générique depuis longtemps. Un type n'implémente pas compareTo(object), il implémente compareTo(T)où Test son propre type. Cela ne peut pas être implémenté object, car objectne connaît pas la classe qui en sera dérivée.

objectaurait pu définir une compareTo(object)méthode, mais cela aurait permis non seulement ce que Snowman souligne, une comparaison entre deux ArrayList<T>s ou entre deux Threads, mais même une comparaison entre un ArrayList<T>et un Thread. C'est encore plus absurde.

Supposons que j'ai deux références d'objet: X identifie une instance de Stringcontenu "George"; Y identifie l'instance de Pointmaintien des coordonnées [12,34]. Considérez les deux questions suivantes:

• X et Y identifient-ils des objets équivalents?

• Est-ce que X doit trier avant, après ou équivalent à Y?

Le fait que X et Y identifient des instances de types non liés ne pose aucun problème lors de l'examen de la première question. Les objets ne peuvent être considérés comme équivalents que si leurs types partagent une base commune qui les définit comme équivalents; puisque Stringet Pointn'ayant pas une telle base (leur seul type de base commun considère tous les objets distincts comme non équivalents) la réponse est simplement "non".

Le fait que les types ne soient pas liés, cependant, pose un énorme problème en ce qui concerne la deuxième question. Certains types définissent les relations de commande entre leurs instances, et certaines relations de commande peuvent même étendre sur plusieurs types [par exemple , il serait possible BigIntegeret BigDecimalde définir des méthodes de comparaison qui permettraient des instances de chaque type à être classés par rapport aux instances de l'autre], mais il n'est généralement pas possible de prendre deux instances arbitraires et de demander "Doit X trier avant, après ou équivalent à Y" et dériver un classement total. Il serait possible de demander "Si X doit trier avant, après, équivalent ou non classé par rapport à Y" si les objets étaient tenus de signaler un ordre cohérent mais pas un totalun, mais la plupart des algorithmes de tri nécessitent des commandes totales. Ainsi, même si tous les objets pouvaient implémenter une compareTométhode si "non classé" était un retour valide, une telle méthode ne serait pas suffisamment utile pour justifier son existence.