,
je n arrive pas a crer mon propre type de comparator.
 
j ai une class Car

 
j aimerai que la comparaison se fasse sur c est 3 parametres L
manufacturer.
model.
model year.
 
comme cela trier un tableau de Cars me donnera celle dont le manufactuereur commence par A, puis model puis annnee ..
Audi A3 2035
Audi A3 2040
Audi A12 2156
Honda ..
ect...
 
Dans mon bouquin ils parlent de

et de  

 
comment dois je my prendre ?
   

a priori t'as pas besoin de Comparator.
 
ecrit juste ta methode compareTo, et ca roule.

un exemple serait le bien venue stp   , j en fais quoi de mon interface Comparable et le methode compareTo quel genre de code dois je y mettre ?

Bin euh... tu sais comment marche une interface ? Ba tu fais public class Car implements Comparable et tu codes toi-même la méthode compareTo()

   
Très mauvaise idée !
 
Ne jamais implémenter Comparable par facilité : uniquement si ca a réellement un sens "universel" pour la classe en question !
 
Dans le cas où tu souhaites juste faire un tri, il faut faire une classe Comparator. La bonne idée c'est de la déclarer en inner classe static provate et de laisser une instance singleton de cette classe en public static final. Un peu à la façon de du comparator non-case sensitive de String

Ouais enfin là, s'il souhaite trier un tableau de Car, il a plutôt intérêt à implémenter Comparable pour pouvoir utiliser java.util.Arrays.sort() derrière.

ben non, il fait comme j'ai dit et utilise java.util.Arrays.sort(Object[], java.util.Comparator)  

Et d'ailleurs pourquoi c'est mal, d'implémenter Comparable ?

ben déjà pare que d'un point de vue design, c'est pas logique. Une voiture, c'est pas "ordonnable", ou plutot y a pas d'ordre unique et niversel pour trier les voitures. Les objets réélement suceptibles d'implémenter Comparable sont relativement rares : les numériques c'est OK, mais même String, quelque part, elle devrait pa ...
 
D'un point de vue moins extremiste, c'est juste que tu vas rencontrer des problèmes quand tu as utiliser certaines classes de l'API Collection. Par exemple, les TreeSet ou autre objet du genre ...

remarque quand tu implémentes Comparable, tu définies un ordre, mais tu définis aussi l'égalité.  
 
Et c'est ca qui pose souvent problème ...

Ba ch'ais pas, moi j'trouve pas ça si mal que ça En implémentant Comparable, tu définis un ordre naturel qui permet d'effectuer un classement qui sera "humainement compréhensible" et c'est bien tout ce qu'on demande. Alors bon, aller faire des singletons avec un Comparator privé et tout le bastringue, j'trouve ça un brin lourdaud

Et si un jour il a la malheureuse envie d'avoir une liste sans doublons (un Set), et que pour ca il utilise un TreeSet, il va passer des heures à comprendre pourquoi y a plein de voitures qui ne sont pas dans son Set ...
 
edit : c'est du vécu hein ! maintenant je fais bien gaffe a ces conneries !

Ba dans ce cas, il aura qu'à lire la doc de Comparable :

Ch'ais pas mais pour un prog qui a juste besoin de faire un Arrays.sort(), je trouve violent de partir dans des considérations de singletons privés et tout

ca a rien de compliqué   !
si il veut pas faire de singleton, qu'il fasse pas de singleton, mais il devra recréer l'objet à chaque fois
 
et puis bon, c'est un conseil, hein, moi je m'en tape.  
Mais pkoi conseiller de faire un truc avec un mauvais design et succeptible d'engendrer des bug vicieux ?

eh ben merci pour toutes ces reponses je vais essayer ca.

 
c est bon ?

non, tu n'a pas de notion d'ordre

Petite question: dois-je écrire absolument implements comprable ? Ou si je peux écrire directement ma méthode sans ça et faire une comparaison avec mes 2 strings d'instances ?
 
genre
 

 
Je gère une exception au cas ou je passe un null, et j'ait fait la même chose avec mon equals, est-ce que il y aurait moyen de faire mieux ?  

 
Explique comment  ça se passe si la comparaison est bien faite, parce que là je vois pas
 
(en même temps va ptet faloir que tu m'explique l'implémentation du treeset, ça semble y être spécifique et je connais pas)

TreeSet c'est juste un Set (collection sans doublon) implémentée sous forme d'arbre (=> plus petit d'un côté, plus grand de l'autre, égale on jette).
Bref, ca se sert de la comparaison.
 
Si le compareTo renvois 0, le TreeSet va considérer que les objets sont égaux => il ne va en garder qu'un. Donc si ta façon d'implémenter Comparable est faite à la légère (qu'elle ne représente pas une façon "universelle" de comparer l'objet), tu risques de perdre des objets sans comprendre pourquoi.
 
Le bon exemple c'est l'objet String : on peut se dire qu'il n'y a pas 36 façon de trier une chaine ... ben en fait si, y en a plein ! Elle ne devrait pas implémenter Comparable, sauf pour des raisons purement pratiques qui ne sont pas recevables devant un jury d'intégristes de l'objet.

oui

oui. Là c'est ni'mporte quoi ton traitement d'exception. Si ta méthode reçoit une référence null, ya aucune raison qu'elle ne lance pas une NullPointerException. Pareil pour le ClassCastException si l'objet passé en paramètre n'est pas du bon type.

En clair, si t'es incapable d'implémenter une comparaison ça nique ton set tout ce qui se base sur des comparaisons, ça me semble logique

Les comparaisons de string par défaut sont toujours alphabétiques, parce que c'est la comparaison de chaînes de caractères la plus utilisée, il est parfaitement logique de fournir la comparaison la plus utilisée pour l'objet en tant que comparaison par défaut

C'est pas la question d'être capable ou non. Ce que je dis c'est qu'une comparaison est souvent dépendente d'un contexte d'utilisation.
 

Ben non, on est pas d'accord. Dire ca c'est mélanger la nature et la fonction de l'objet.  
C'est quoi ta définition de l'ordre alphabétique ?
un 'A' c'est avant ou après un 'b' ?
et un é c'est avant ou après un e qui est avant ou après un 'ë' ?
 
Regarde la comparaison par défaut de String, et tu verras que ca ne répond pas de la même façon que toi à ces questions ...
 
Qui a raison ? qui a tort ?
Dès qu'il y a la moindre incertitude, ca veut dire que l'objet ne doit pas être Comparable, mais accompagné de Comparators

Celle de String(Java) aucune idée, mais celles de string (Python) comme celle de String(Ruby) correspondent parfaitement à ma définition:

>>> sorted(["bfoo","ëfoo","Afoo","éfoo","efoo"])
['Afoo', 'bfoo', 'efoo', '\xe9foo', '\xebfoo']

>> ["bfoo","ëfoo","Afoo","éfoo","efoo"].sort
=> ["Afoo", "bfoo", "efoo", "\351foo", "\353foo"]

(resp. \xe9 et \351 pour "é" et \xeb et \353 pour "ë" )
 
 
edit: Ah ben java me sort strictement le même ordre, donc tout va pour le mieux dans le meilleur des mondes pour autant que je sois concerné

l'ordre alphabétique est "culturel" (dépendant de la Locale) => il n'y a pas de définition unique.
 
edit : http://java.sun.com/j2se/1.5.0/doc [...] ng.String)

J'ai regardé ce que donnait un Arrays.sort(String[]) en java, voir mon edit

va falloir que je vérifie ça moi    
 
mais remarque, peut importe (cf. mon dernier post)

import java.util.Arrays;
 
class TestSort {
    public static void main(String args[]) {
        String[] foo = {"bfoo","ëfoo","Afoo","éfoo","efoo"};
        for(int i=0; i<foo.length; ++i)
            System.out.print(foo[i]+" " );
        System.out.println("" );
        Arrays.sort(foo);
        for(int i=0; i<foo.length; ++i)
            System.out.print(foo[i]+" " );
    }
}

(oui c'est moche, je sais )
Output:

δ = ë et Θ = é, donc, d'où ordre identique aux deux autres
(avec Java5 en tout cas)
 

Sur un alphabet donné chuis pas sûr... à la limite on peut discuter sur la position des variantes accentuées (et autres cédilles) dans les alphabets romains par exemple, mais pas beaucoup plus

j'étais quasi sûr que ca ne se servait que de la valeur du code unicode pour faire la comparaison ... bizare ... j'ai du mal à imaginer qu'ils aient changer ça d'une version de java à une autre
 
mais comme je disais, de toute façon ca DOIT dpendre de la Locale => ca ne devrait pas être Comparable (sauf à être une classe Générique : String<T extends Locale> )

 
Juste par curiosité, comme il y a un tri à faire sur plusieurs attributs de la classe, comment coderiez-vous alors son problème (code) ?  

en gros :  
 
si this.att1 < o.att1, return -1
si this.att1 > o.att1, return +1
si this.att2 < o.att2, return -1
si this.att2 > o.att2, return +1
...
return 0;

 
  aok très simple finalement.