Discussion :

[onlytoine]

hello,

Dans la série "je martyrise les listes", je voulais savoir s'il existe en java le moyen d'être notifié lors d'ajout et de suppression d'élément dans une liste ?

L'idée est de pouvoir intercepter les ajouts par exemple, pour faire un traitement.

Ou encore interdire une opération.

Merci !

Anthony

PS : j'en appelle à vos connaissances, si ça n'existe pas je saurai me débrouiller !

[Tommy31]

Tout à fait possible avec cette lib: http://publicobject.com/glazedlists/...azedLists.html

C'est une lib robuste, employée dans le projet Spring RCP.

[onlytoine]

Hmmm c'est bon ça !

Je vais voir les aspects de licence...

Merci en tout cas, je ne connaissais pas !

Anthony

[onlytoine]

Par contre, j'ai l'impression que tu es prévenu après que l'opération soit effectuée ?

Dans mon cas, je dois parfois interrompre un ajout par exemple si l'objet ne respecte pas certaines conditions.

Anthony

[natha]

Fait ta propre implémentation de List dans ce cas.

[onlytoine]

Oui... Je suis un peu fainéant et donc si certains se sont déjà penché sur le problème et que je peux bénéficier de leur travail...

[Grimly_old]

Reprends le principe des listes non-nulles que je t'ai donné et rajoute un Listener (que tu peux créer intégralement, c'est toi le maître de ton code ) qui sera appelé à chaque commande pour jeter une exception (fait la hériter de RuntimeException ou Error pour ne pas géner l'interface List).

[Tommy31]

Une implémentation propre, c'est peut être pas l'idéal. D'abord parce qu'on peut vouloir diverses stratégie d'implémentations qui conservent pour autant le même principe de notification évènementielle. Ensuite parce que le code que tu fais, c'est une source de bug supplémentaire et du code à maintenir en plus.

Ce que je te conseille pour ton cas, c'est un pattern proxy. Prends cette lib, google list (qui atomise les common collections), et implémente juste le système de notification en partant d'un ForwardingList<E>.

[natha]

Une implémentation propre, c'est peut être pas l'idéal. D'abord parce qu'on peut vouloir diverses stratégie d'implémentations qui conservent pour autant le même principe de notification évènementielle.

Sous forme de wrapping ça limite les bugs quand même.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class MaList implements List {
 
    private List wrapper = new ArrayList();
 
    public void add(Object obj) {
        // mon test d'ajout
        wrapper.add(obj);
    }
 
    // etc.
 
}

[Tommy31]

C'est très précisément la solution que j'ai proposée

[onlytoine]

Le plus délicat pour la liste, c'est qu'il y a des opérations indirectes... Je veux dire par exemple, pour la méthode retainAll(), il faut gérer un évènement de supression pour les éléments qui seront supprimés... (il faut les déterminer)

Pareil pour les Iterator qui permet des modificaitions de la liste... bref, ce n'est pas un proxy trivial.

En tout cas, je vais regarder tout ça pour voir si je peux m'en inspirer pour améliorer ma solution.

Anthony

[Tommy31]

Exact, le retainAll s'adresse à l'itérateur de la liste, qui désigne la liste proxifiée et non le proxy.

Seule solution garantie à 100% est le recours a un aspect weavé. C'est propre, élégant mais ca nécessite une mise en oeuvre plus lourde.

[onlytoine]

Tiens, c'est dommage... Il existe :

com.google.common.collect.Constraints.constrainedList(List<E> list, Constraint<? super E> constraint)

mais malheureusement, ils n'ont pas poussé le concept assez loin car ils ont effectivement Constraints.NOT_NULL mais l'interface Constraint n'a qu'une méthode checkElement(E element)... On ne peut pas distinguer un ajout, d'une suppression.... (enfin je pense qu'elle est appelée uniquement en cas d'ajout)

Anthony

[onlytoine]

ouaip c'est sur que d'introduire de l'AOP pour ça, c'est pas toptop... je passe plutot par un adaptateur dans mon cas qui a le role de sous-proxy vers l'itérateur.