Récupération dans table de hachage d'une clé par une valeur

Bonjour à tous,

J'ai un petit problème que voici :

J'ai une classe collection qui contient des entrées. Ces entrées sont stockées dans une table de hachage à l'aide de l'identificateur de l'entrée et l'entrée elle même. (Les identificateur des entrées ne se suivent pas forcément)

J'ai une autre classe qui implémente l'interface TableModel qui contient un objet collection et une table de hachage permettant de faire la correspondance entre les entrées de la collection et l'indice utilisé par exemple par une JTable.
C'est-à-dire que lorsque, par exemple, ma JTable me demande la valeur à la ligne 10, je vais regarder dans ma table de hachage afin de retourner l'entrée correspondant à la position 10.
ex. : return collection.get(correspondance.get(10));

Jusque là tout va bien...

Le problème viens lorsque je supprime une entrée de ma collection. Je dois avertir mon table model comme quoi l'entrée ayant l'id xxx a été supprimé. Mon table model doit ensuite envoyer un événement à ma JTable pour lui avertir que la ligne xxx a été supprimée.

Voici comment ça se passe :
je supprime dans ma collection l'entrée, puis un événement est envoyé (selon le modèle observateur) en passant l'identificateur de l'entrée supprimée.

J'arrive enfin au problème :?
mon tableModel reçoit un événement qui lui donne l'identificateur de l'entrée supprimée. Le problème c'est que la table de hachage ne permet pas de récupérer la clé (ou la liste des clés) correspondant à une valeur (tandis que l'on peut quand même tester l'existence d'une valeur...) et que j'ai besoin justement de la clé pour avertir la JTable de la ligne qui a été supprimée.

La seule solution que j'ai trouvée est de créer deux tables de hachage faisant le lien dans les deux sens. Mais cette solution ne me plaît pas beaucoup car cela prend plus de place mémoire.

Est-ce que quelqu'un connaît une meilleure solution? elle serait la bien venue! Merci d'avance.

P.S.: J'espère que j'ai réussi à me faire comprendre. je peux donner des compléments si vous avez besoin ;)

il y a une classe BidiMap dans jakarta commons collections qui fait ce que tu veux très bien :

http://beuss.developpez.com/tutoriel...s/collections/

Super merci bien c'est exactement ce que je voulais.

Je ne connais pas tellement le contexte du problème, mais il me semble que la conception peut être améliorée...

"es entrées sont stockées dans une table de hachage à l'aide de l'identificateur de l'entrée et l'entrée elle même."
==> Pourquoi ne pas faire une classe:

Code:

---

1 2 3 4 5

class Entree { TypeID id; TypeValue value; //accesseurs... }

---

Et tu ranges ces Entrees dans une ArrayList... comme ça tu n'as pas de problème...

En fait j'ai stocké tout ça dans une table de hachage afin d'avoir un accès en temps constant. Tandis qu'une liste
n'a qu'un accès en O(n).

De plus les entrées d'une collection doivent être accessible par un identificateur, tandis que dans une liste elles seraient accessible selon leur position. du coup pour supprimer une entrée il me faudrait que j'y accède en utilisant liste.get(liste.indexOf(entree)) ce qui double le temps d'accès .

C'est bien beau tout ça mais tu oublie un peu la cuisine interne de ta hashmap dans tes calculs de complexité...

Je suis tout a fait d'accord, mais quand tu sais que lorsque ta JTable va récupérer constamment des informations dans le model, sous prétexte que tu passes la souris sur les cellules ou que tu descends un scroll, agrandi la fenêtre etc... et que tu as pas mal d'informations à afficher, la complexité d'ajout dans la hashmap peut être négligée... enfin c'est ce que je pense.

Citation:

---

Envoyé par Sebbo

En fait j'ai stocké tout ça dans une table de hachage afin d'avoir un accès en temps constant. Tandis qu'une liste
n'a qu'un accès en O(n).

---

Non, si ta liste implément RandomAccess (comme ArrayList par exemple), la complexité est en O(1), et en plus, y'a aucun calcul à faire (contrairement au hash).


En gros, pour get():
- ArrayList -> O(1)
- LinkedList -> O(n)

Tiens je savais pas... merci du renseignement. je vais un peu creuser...