contrainte de symétrie sur compareTo()

Version imprimable

03/11/2016, 16h38
shaiHulud

contrainte de symétrie sur compareTo()

Bonjour,

Je suis en train d'implémenter Comparable pour une de mes classes, mais les contraintes suivantes me laissent perplexe (tirées de javapractices):

Citation:

anticommutation : x.compareTo(y) is the opposite sign of y.compareTo(x)
exception symmetry : x.compareTo(y) throws exactly the same exceptions as y.compareTo(x)

Vu que je peut recevoir n'importe quel Object other en argument de compareTo(Object other), je n'ai absolument aucune idée de l'implémentation de compareTo() dans la classe concrète que je recois (qui peut d'ailleurs ne pas l'implémenter).

Je pourrais lancer une erreur si la classe de other n'est pas celle de this, et espérer que other.compareTo(this) fasse la même chose; mais même là, ce n'est pas satisfaisant pour trier une Collection contenant des Object heterogènes.

Comment suis-je censé procéder ?
Merci d'avance.

Bonjour,
L'interface comparable est "paramétré" :

Code:

Interface Comparable<T>

Ce qui veux dire que si tu veux implémenter cette interface, il faudra que tu indique avec quoi celle-ci est comparable (le T)

Exemple d'implémentation :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
package developpez;
 
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
 
public class Toto implements Comparable<Toto> {
  public Toto(int value) {
    this.value = value;
  }
  public int value;
 
  public int compareTo(Toto anotherToto) {
    return this.value - anotherToto.value;
  }
  public static void main(String[] args) {
    List<Toto> list = new ArrayList<>();
    list.add(new Toto(7));
    list.add(new Toto(4));
    list.add(new Toto(1));
    list.add(new Toto(10));
    list.add(new Toto(9));
    list.add(new Toto(2));
    System.out.println("Avant le tri !");
    for (Toto toto : list) {
      System.out.println(toto.value);
    }
    System.out.println("Après  le tri !");
    Collections.sort(list); // sort utilise l'interface comparable pour faire le tri
    for (Toto toto : list) {
      System.out.println(toto.value);
    }
  }
}

L'ensemble des explications complémentaires sont données dans la documentation.

Cordialement,
Patrick Kolodziejczyk.

source :
Javadoc Comparable

15/11/2016, 11h26
shaiHulud

Merci Kolodz,

Mais que se passe-t'il si T n'implémente pas Comparable (par exemple une super classe, voir même Object) ?
Dans le cas d'Object, la contrainte de symétrie est impossible à satisfaire, car on ne sait pas si on recoit un Comparable ou non, et si ce comparable accepte this !

Quel est le danger à implémenter compareTo(Object) tel que (par exemple) this.compareTo("string") soit différent de "string".compareTo(this) ?

Je me dis naivement que si ca posait un réel problème, <T> serait déclaré <T extends Comparable>
15/11/2016, 19h58
professeur shadoko

Très bonne remarque
on a des exemples où cette symétrie n'est pas respectée ( par ex. Timestamp et Date)
je me demande comment il faut réellement interpréter la spécification (et ce n'est pas la première fois où on trouve des specs ambiguës ...)
en fait cette contrainte : The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)
devrait effectivement être comprise comme x et y de type T et non pas extends T ...
16/11/2016, 11h25
shaiHulud

Merci professeur shadoko,

Citation:

en fait cette contrainte :...
devrait effectivement être comprise comme x et y de type T et non pas extends T ...

C'est mon sentiment aussi, alimenté par les cas "Object".

Ce qui me gêne toutefois, c'est lorsque la relation d'ordre a du sens sur une hiérarchie de classe. Par exemple une classe abstraite Figure avec des implémentations cercle, carré... que l'on compare par surface. Dans ce cas, on a envie de respecter la contrainte sur l'ensemble des sous-types de Figure.
16/11/2016, 14h44
professeur shadoko

il me semble que l'un n'empêche pas l'autre ...
on a ce cas avec equals : il peut être pertinent d'avoir un equals avec une instance d'une sous-classe (bon d'accord: equals est equals(Object) et n'est pas paramétrée)
mais dans ton cas la comparaison par compareTo ne me semble pas constituer un ordre "naturel" ... il vaudrait mieux avoir un Comparator
16/11/2016, 15h07
shaiHulud

Oui, c'était juste un exemple inventé en 22. Un Comparator serait mieux, mais parfois on a pour contrainte d'implémenter Comparable.