Discussion :

[nadsky]

bonjour,j'avais une question concernant le transtypage,en particulier à travers son utilisation pour la méthode CompareTo.
je pensais que le transtypage permettait de transformer un type de base(int,float..)en objet.
Or,un de mes programmes consistaient à trier des comptes bancaires(d'une classe compte) selon un critère(soit le numéro de compte,soit le solde...)et j'ai choisi de trier ces comptes selon le solde(float).
et voici deux corrigés possibles:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
 
public int compareTo(Object o){
float r=soldeCompte-(((Compte)o).soldeCompte);
return (int) r;
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public int compareTo(Object o){
Float solde = new Float(soldeCompte);
return solde.compareTo(((Compte)o).soldeCompte);
}

pourriez-vous m'expliquer d'une part la signification de ces lignes de code et ensuite la différence entre ces deux versions?
merci d'avance

[strate]

Arrête ça tout de suite malheureux !

Les floats sont faits pour representer des valeurs continues avec une certaine précision, typiquement des résultats de mesures physiques.

Un float n'est pas fait pour représenter un solde bancaire, qui est une valeur discrète (pas continue) exacte (sans notion de précision).

Les floats ont pleins de propriétés surprenantes : par exemple un float ne peut pas représenter de façon exacte la valeur 0.01. Tant que tu ne maitrises pas ça, ne les utilise pas, tu t'exposes à des erreurs de calcul pas tristes. L'option la plus simple pour représenter un solde bancaire est de mettre des centimes dans un entier. Tu peux aussi te définir ton propre type si tu préfères bien séparer unités et centimes.

Sinon pour ta méthode compareTo, le plus propre est de d'abord caster le paramètre o vers le type qu'il te faut, et ensuite de faire l'opération sur ce type. N'oublie pas de faire une vérification de type avant le cast.

[bmeurant]

bonjour,

Petite rectification : nul besoin de faire une vérification de type ou même de tester la valeur null, au contraire, cela rompt le contrat obligatoire définie par l'API Java pour toute implémentation de compareTo :

null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException

ce qui signifie : pas de test if (o != null) ou alors on propage NullPointerException ce qui ne sert à rien ...

Throws:
ClassCastException - if the specified object's type prevents it from being compared to this Object.

ce qui signifie : pas de vérification de type ou alors on propage ClassCastException ce qui ne sert à rien. sauf dans le cas où tu souhaites comparer deux objets de classes différentes ais ce n'est pas conseillé car source de buggs très tordus.



Moralité : si on ne fait aucune vérification, on respecte parfaitement le contrat, c'est pas beau ça ?

Pour le reste, le mieux est de se reporter à l'API Java pour le contrat complet de compareTo. je le poste quand même ici au cas où tu as la flemme :

Compares this object with the specified object for order. Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.

In the foregoing description, the notation sgn(expression) designates the mathematical signum function, which is defined to return one of -1, 0, or 1 according to whether the value of expression is negative, zero or positive. 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.)

The implementor must also ensure that the relation is transitive: (x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0.

Finally, the implementer must ensure that x.compareTo(y)==0 implies that sgn(x.compareTo(z)) == sgn(y.compareTo(z)), for all z.

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

Parameters:
o - the Object to be compared.
Returns:
a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.
Throws:
ClassCastException - if the specified object's type prevents it from being compared to this Object.

Le respect du contrat n'est pas une lubie, ne pas le respecter peut engendrer des erreurs très complexes et difficiles à trouver - notamment lors de la manipulation de listes ou de Maps (même remarque pour equals et hasCode).

Concernant les Floats, je ne suis pas spécialiste mais cela peut effectivement se modéliser par deux entier : un pour la partie entière et l'autre pour la partie décimale. Dans ton compareTo, tu commence par comparer les valeurs entières puis, si elles sont égales, les valeurs décimales. au passage, tu optimises le code (les Floats sont des objets parfois lourds à manipuler).

Bonne comparaison,

Baptiste

[CyberChouan]

Concernant les Floats, je ne suis pas spécialiste mais cela peut effectivement se modéliser par deux entier : un pour la partie entière et l'autre pour la partie décimale. Dans ton compareTo, tu commence par comparer les valeurs entières puis, si elles sont égales, les valeurs décimales. au passage, tu optimises le code (les Floats sont des objets parfois lourds à manipuler).

Personnellement, je modéliserait le solde du compte bancaire par un unique entier représentant le solde en centimes d'euros (et d'ailleurs plutôt en utilisant un long qu'un int... il y a des gens riches )

Mais bon... c'est un autre débat!