traitement dans une collection

slt je dispose d'une collection de type HashMap,où je réalise des traitements (put,remove,..).J'aimerais savoir comment faire des notifications dans un HashMap.
toute idée,conseil,ou assistance serais la bien venus.
a++;)

Peux tu être plus précis, quelles notifications veux tu faire ? Qui doit notifier quoi à qui ?

par exemple un insertion,modification ou suppression d'une valeur.notons que ma collection est solliciter par plusieurs user ceci à travers un thread. ainsi j'aimerais qu'après chaque traitement réalisé dans la collection une notification soit fait afin que chacun est accès au même contenu.

Il n'y a pas de listeners dans les Maps, mais tu peux en écrire une en suivant le pattern Decorator. Un truc du genre :

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

public class ListenableMap<K, V> implements Map<K, V> { private Map<K, V> backedMap; private List<MapListener> listeners = new ArrayList<MapListener>();   public ListenableMap(Map<K, V> backedMap) { this.backedMap = backedMap; }   public void addMapListener(MapListener listener) { listeners.add(listener); }   public void removeMapListener(MapListener listener) { listeners.remove(listener); }   public V put(K key, V value) { V v = backedMap.put(key, value); fireDataPut(key, value); return V; }   protected void fireDataPut(K key, V value) { // appel de la méthode associée pour chaque listener. }   ...... }

---

Tu as juste à créer l'interface MapListener et implémenter toutes les méthodes de Map en ajoutant la gestion des évenements qui t'intéresse.

je profite de la réponse de le y@m's
Dans un cas comme celui-ci, est-ce qu'il est plus propre de créer une classe qui implémente l'interface (comme le propose le y@m's) ou une classe héritante de la classe HashMap

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

public class ListenableMap<K, V> extends HashMap<K, V> { private List<MapListener> listeners = new ArrayList<MapListener>();   public ListenableMap() { }   public void addMapListener(MapListener listener) { listeners.add(listener); }   public void removeMapListener(MapListener listener) { listeners.remove(listener); }   public V put(K key, V value) { V v = super.put(key, value); fireDataPut(key, value); return V; }   protected void fireDataPut(K key, V value) { // appel de la méthode associée pour chaque listener. }   ...... }

---

D'un point de vue code, cela reste identique, et d'un point de vue abstraction, à mon avis cela ne change rien.
En fait, la question se pose que sur un plan de conception (spécialisation de HashMap) et sur un plan de performance et d'utilisation de mémoire.

Citation:

---

Envoyé par akkai

D'un point de vue code, cela reste identique, et d'un point de vue abstraction, à mon avis cela ne change rien.

---

- Il y a de gros risques d'oublier de redéfinir une méthode qui doit être redéfinie. Avec une interface c'est impossible, le compilateur le refuserait.
- La Map expose alors qu'elle est spécialisée en tant que HashMap, elle expose les méthodes spécialisées de la HashMap, ses propriétés, etc. Si un jour les HashMap devaient définir des méthodes spécialisées qui peuvent modifier leur contenu, ListenableMap ne va pas le faire automatiquement et cessera de remplir son rôle.
- Si un jour on voulait pouvoir choisir l'implémentation de la Map qu'on écoute (TreeMap, LinkedHashMap, synchronizedMap(), que sais-je,) Le modèle de l'interface avec encapsulation le permettrait. Le modèle d'extension, non.

Citation:

---

Envoyé par akkai

En fait, la question se pose que sur un plan de conception (spécialisation de HashMap) et sur un plan de performance et d'utilisation de mémoire.

---

Pas spécialement sur un plan de performance ni d'utilisation mémoire, non. Sauf si tu parles de la possibilité de pouvoir choisir entre HashMap et TreeMap.

slt voilà j'ai du mal à cerné certain point de ce code:
1-pourquoi crée un interface MapListener implémentant toute les méthodes de Map alors que la classe ListenableMap les implémentes déjà.
2-la fonction V de quel type est elle?
3- quand vous parler de gestionnaire des événements,je ne comprend par car je ne gère aucun événement particulier.
ainsi toute aide,conseil ou assistance serais la bien venus.
a++:(

Citation:

---

Envoyé par narutoe

slt voilà j'ai du mal à cerné certain point de ce code:
1-pourquoi crée un interface MapListener implémentant toute les méthodes de Map alors que la classe ListenableMap les implémentes déjà.

---

Désolé ma phrase était un peu mal tournée. Je voulais dire qu'il te fallait créer l'interface MapListener (avec les méthodes correspondant aux évènements que tu gérer), et implémenter toutes les méthodes de Map dans la classe ListenableMap (car dans mon exemple je ne le faisais que pour une seule méthode afin d'illustrer le principe).

Citation:

---

Envoyé par narutoe

2-la fonction V de quel type est elle?

---

Ce n'est pas une fonction, il s'agit des generics qui te permettent de typer ta Map (cf Qu'est-ce que les Generics (types paramétrés) ?).

Citation:

---

Envoyé par narutoe

3- quand vous parler de gestionnaire des événements,je ne comprend par car je ne gère aucun événement particulier.
ainsi toute aide,conseil ou assistance serais la bien venus.
a++:(

---

Ton souhait est bien d'être notifié lors d'opérations (ajout, suppression) sur les éléments de ta Map ? Donc avec ce système de listener tu génères un évènement lors d'une opération dont tu souhaites une notification. Ces évènements sont remontés aux listeners abonnés à la Map. Si besoin voici un tutoriel sur les listeners ;).

Pour faire simple:
-> Le Decorator est l'implémentation la plus souple (on peux choisir son implémentation)
-> le classe fille est une implémentation à la va vite généralement acceptable pour les besoins simples.

Mais ce que vos voulez faire nécessite beaucoup de boulot. Car on peux modifier une Map via put / remove / clear / putAll / etc , mais aussi via les entrySet, les keySet, etc. Donc ça fait une tartine de décorateurs supplémentaires à écrire, quelle que soit la stratégie choisie.