Reprise du message précédent :

C'est qu'on a pas la même définition de double dispatching -> http://www.chimu.com/publications/ [...] ching.html
Et pour la valeur unique je crois que t'as pas compris (mon explication était pas brillante...):
'b'   'l'   'a'   'b'  'l'  'a'
 ^     ^     ^     ^    ^    ^
 |     |     |     |    |    |
205   223   204   205  223  204
 
total (une addition avec des multiplication) = 205223204205223204 -> une valeur unique, mais par contre je sais si ca trouve dans l'intervalle du switch... je proposais cela pcq le switch accepte pas les strings apparement (en java) et que de cette facon tu obtiens un chiffre unique pour chaque string

Ooops, désolé

Au fait t'as raison, j viens de revoir ton code et c'est du simple dispatching
Le double est utilisée dans des cas spéciaux... désolé Ca m'apprendra à pas bien lire le code et à répondre trop vite  

> _gtm_ je n'avais pas compris ton truc de cette façon, et en effet, la méthode sera bien souvent plus efficace.

sinon, pour info, je relève certains truc dans ce que tu as dit :  
 

 
Ca ca dépend énormément des cas : par exemple si les deux chaines sont de taille différentes => c'est pas égal => on a résolu le equals en 1 test. Le hascode lui iterera sur toute la chaine.
 
Dans le cas des chaines de caractères, et sans parler de la mise en cache du calcul du hashcode, un equals est bien plus rapide qu'un hashCode !
 

Dans une HashMap, c'est fait comme ca :  après avoir déterminé l'index (hashCode modulo taille du tableau), il va falloir parcourir une liste chainée. Sur chacun des élément de cette liste chainée, on va calculer le hashCode + faire un equals dans le cas ou le hashCode est identique.
 
Mais sinon, je suis bien d'accord : statistiquement, c'est plus efficace dans le cas où on doit tester l'égalité avec bcp de chaines.
 
Mais pour les cas habiuels, une suite de if sera bien meilleur en perf et en utilisation mémoire !

benou : je ne suis pas sur que la HashMap soit implémentée comme ça. Ou alors qu'il y aurait une autre classe qui ferait mieux ce que je cherche.
 
Voilà comment je vois ma HashMap :  
Pour insérer un élément : on calcule une valeur de hachage. Ensuite, on applique une autre fonction surjective à cette valeur de hachage pour obtenir une classe d'équivalence. Par exemple ont peut réduire les valeurs hachées à l'intervalle [0.255]. On insère notre élément dans cette classe d'équivalence (qui peut être une liste chaînée).
 
Pour la recherche d'un élément : On calcule la valeur de hachage de l'élément recherché, et on en déduit la classe d'équivalence. Il faut ensuite faire des comparaisons avec les éléments de notre classe d'équivalence, mais on va en avoir 1/255ème du nombre d'éléments au total, et c'est là qu'on gagne beaucoup de temps.
 
Mais c'est vrai qu'avec peu d'éléments (genre une demi-douzaine), les ifs vont être plus efficaces. Mais tu auras du remarquer que je n'aime pas les ifs et les switch

Bah, sinon, le coup de calculer des valeur uniques en types primitifs pour faire un switch en Java, je crois pas que ça marche : il me semble que le switch ne peut prendre que des constantes en argument de chaque case...
 
Mais sinon, pour apporter de l'eau au moulin de __gtm__, quand j'étais encore u jeune padawan de la programmation de protocole réseau pour un chat, j'avais fait avec un switch : une méthode me renvoyait un objet, par l'intermédiaire d'un gros switch tout moche sur les ID des messages reçus...
Maintenant, j'ai une jolie Hashtable, avec des Integer comme clés, et des objet Factory comme valeur...Ben j'ai gravement gagné en souplesse (parce que la correspondance clé->classe Factory est stockée dans un fichier, donc, si j'ajoute un message, hop, j'ai que la classe à écrire et le fichier à mettre à jour)  
 
Donc, le switch, ça pue du rond...

gfive a écrit a écrit :   Donc, le switch, ça pue du rond...

 
conclusion que je partage  

j'ai étudié le code source de la HashMap donc je te certifie que ca fonctionne bien comme je te l'ai dit, ce qui reviens au même que ce que tu viens de détailler.
 
par défaut la taille d'une HashMap (ou la grandeur de l'interval de la classe d'équivalence si tu préfère) est 11.  
 
et puis tu sais, commeje te le disais, dans la majorité des cas, un hashcode sera bien plus long qu'un equals.
 
Sinon je suis d'accord pour dire que c'est un pattern intéressant. D'ailleur je l'ai déjà utilisé ...

DarkLord a écrit a écrit :     conclusion que je partage

 
Quand même, faut en écrire, des conneries pour arriver à pondre un résumé aussi efficace de la situation!