Discussion :

[®om]

Salut,

En respectant le design pattern MVC, on a en particulier un modèle et une vue.
Dans certains cas, le modèle contient des classes avec des méthodes

Code :

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

1
2
void addXListener(XListener listener);
void removeXListener(XListener listener)

Lorsqu'on les exécute à partir de la vue, par exemple avec

Code :

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

myModelClass.addXListener(myListener)

, en général on stocke ces listeners dans une List<XListener>.

Le problème, c'est que la vue est référencée dans le modèle... Enfin, me direz-vous, c'est normal, c'est ce que l'on cherche à faire...
Mais le problème, c'est que quand on nullifie un objet, et qu'il n'est plus référencé, par exemple:

Code :

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

1
2
String s = "abc";
s = null;

alors le Garbage Collector le supprime (tôt ou tard) de la mémoire.

Etant donnée que dans le cas cité ci-dessus, la vue est référencée par le modèle, si on nullifie un élément de la vue écouté, il n'est pas supprimé de la mémoire, et il n'est plus référencé que par le modèle (et en plus il est inaccessible).

Y'a-t-il un moyen (un pattern) pour indiquer au Garbage Collector de supprimer les objets uniquement référencés dans les List<XListener>, sans faire de removeXListener manuel?

Merci d'avance :-)

[adiGuba]

Lorsqu'on les exécute à partir de la vue, par exemple avec

Code :

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

myModelClass.addXListener(myListener)

, en général on stocke ces listeners dans une List<XListener>.

Tu peux également d'utiliser un EventListenerList (voir la FAQ : Comment créer son propre Listener ?signal_si_nouveau(conv_date("23/03/2002"));signal_si_mise_a_jour(conv_date(""))

Y'a-t-il un moyen (un pattern) pour indiquer au Garbage Collector de supprimer les objets uniquement référencés dans les List<XListener>, sans faire de removeXListener manuel?

Oui c'est possible. Il faut utiliser WeakReference (référence faible) qui authorise le GC à supprimer un objet lorsqu'il n'existe aucune autre référence normal vers ce dernier.

Plus d'info : Comprendre les Références en Java

Seul problème : entre le moment où ta référence est passé à null et celui ou l'objet est bien supprimé, il peut se passer beaucoup de temps, et tu peux donc te retrouver à envoyer des évenement à un objet qui ne devrait pas les recevoir...

a++

[®om]

Oui c'est possible. Il faut utiliser WeakReference (référence faible) qui authorise le GC à supprimer un objet lorsqu'il n'existe aucune autre référence normal vers ce dernier.

Plus d'info : Comprendre les Références en Java

Alors là, un grand merci !
(enfin, même si tu me fais réécrire une partie du noyau de mon appli lol, même les SoftReference sont intéressante, je viens justement d'écrire un truc de gestion de cache).

Seul problème : entre le moment où ta référence est passé à null et celui ou l'objet est bien supprimé, il peut se passer beaucoup de temps, et tu peux donc te retrouver à envoyer des évenement à un objet qui ne devrait pas les recevoir...

Ouais
Mais bon, ça n'est qu'un problème amoindri du problème initial

[®om]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    /**
     * Ajoute un écouteur de lecture.
     * 
     * @param listener
     *            Écouteur.
     */
    public void addPlayListener(PlayListener listener) {
        assert listener != null : "Le listener ne doit pas être null.";
        playListeners.add(new WeakReference<PlayListener>(listener));
    }
 
    /**
     * Enlève un écouteur de lecture.
     * 
     * @param listener
     *            Écouteur.
     */
    public void removePlayListener(PlayListener listener) {
        assert listener != null : "Le listener ne doit pas être null.";
        //playListeners.remove(listener);
    }

Par contre, pour removeXListener, on est obligé de parcourir la liste à la main, on ne peut pas faire de .remove(listener) directement

EDIT: Est-ce que l'utilisation des WeakListener est vraiment recommandé pour créer ses listeners (d'ailleurs, il me semble que les listeners de java ne les utilisent pas)?
Je vais les utiliser, mais c'est vrai que ça complique pas mal le code source à certains endroits...

Code :

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

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
    /**
     * Enlève un écouteur de lecture.
     * 
     * @param listener
     *            Écouteur.
     */
    public void removePlayListener(PlayListener listener) {
        assert listener != null : "Le listener ne doit pas être null.";
 
        boolean found = false;
        int i = 0;
        while(i < playListeners.size() && !found) {
            PlayListener l = playListeners.get(i).get();
            if(l != null) {
                if(l.equals(listener)) {
                    found = true;
                    playListeners.remove(i);
                } else {
                    i++;
                }
            } else { // l == null
                /* Valeur nulle, on la supprime, et donc on n'incrémente pas i. */
                playListeners.remove(i);
            }
        }
        // playListeners.remove(listener);
    }

Sinon, une autre question qui n'a rien à voir, mais pourquoi dans la classe Collection, qui est paramétrée, la méthode .add demande en paramètre un objet de type T (paramétré), et .remove demande un Object...?

[adiGuba]

Par contre, pour removeXListener, on est obligé de parcourir la liste à la main, on ne peut pas faire de .remove(listener) directement

Il te faut héiter de WeakReference pour surcharger la méthode equals() pour qu'elle vérifie la valeur de la référence qu'elle contient, et ensuite créer une WeakReference temporaire pour la suppression (ainsi remove() pourra fonctionner car il se base sur equals())...

EDIT: Est-ce que l'utilisation des WeakListener est vraiment recommandé pour créer ses listeners (d'ailleurs, il me semble que les listeners de java ne les utilisent pas)?
Je vais les utiliser, mais c'est vrai que ça complique pas mal le code source à certains endroits...

Avec Swing en général c'est à la charge de chaque listener de se "supprimer" des composant auquel il s'est enregistrée... mais rien n'interdit d'utiliser des WeakReference... et c'est vrai que cela peut compliquer un peu les choses...

Sinon, une autre question qui n'a rien à voir, mais pourquoi dans la classe Collection, qui est paramétrée, la méthode .add demande en paramètre un objet de type T (paramétré), et .remove demande un Object...?

Il me semble que si tu joue avec les méthodes equals(), tu peux utiliser des types différents pour supprimer un objet. Tu peux ainsi avoir un type complet (avec plein d'attributs) que tu stocke dans la liste, et un type de base (avec seulement les attributs permettant de l'identifier) pour supprimer l'élément complet correspondant...

a++

[®om]

Il te faut héiter de WeakReference pour surcharger la méthode equals() pour qu'elle vérifie la valeur de la référence qu'elle contient, et ensuite créer une WeakReference temporaire pour la suppression (ainsi remove() pourra fonctionner car il se base sur equals())...

Avec Swing en général c'est à la charge de chaque listener de se "supprimer" des composant auquel il s'est enregistrée... mais rien n'interdit d'utiliser des WeakReference... et c'est vrai que cela peut compliquer un peu les choses...

Ouais, au début j'avais pensé qu'ils avaient mis une methode equals() qui transmet le equals() sur l'élément correspondant...
Mais bon, ça doit poser problème pour les ReferenceQueue ou qqch comme ça, et ça doit être pour ça qu'ils ne l'ont pas fait...

Il me semble que si tu joue avec les méthodes equals(), tu peux utiliser des types différents pour supprimer un objet. Tu peux ainsi avoir un type complet (avec plein d'attributs) que tu stocke dans la liste, et un type de base (avec seulement les attributs permettant de l'identifier) pour supprimer l'élément complet correspondant...

Ah ouais, je n'avais pas pensé à ça...

Enfin, je trouve ça un peu dommage quand même, car les generics, ça sert à pas se tromper de type, et quand j'ai changé XListener en WeakReference<XListener>, ça ne m'a souligné que le .add et pas le .remove...

Enfin, merci, tu as réponse à tout dis-donc !