Discussion :

[flool]

Bonjour,
Je suis en train de creer un logiciel en java et j'aurais besoin d'un avis pour voir si je me trompe sur un point.
Je voulais utiliser Observer/Observable pour faire communiquer la partie IHM et la partie Métier.
Seulement étant donné que l'extends est limité, j'ai utilisé des classes internes du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
     
/* Classe interne qui fait observer les modifications */
class Observe extends Observable{
    public void notifier() {
        super.setChanged();
        super.notifyObservers();
    }
    public void notifier(Object p) {
        super.setChanged();
        super.notifyObservers(p);
     }           
}

J'aurais aimé avoir votre avis sur la pertinence de cette méthode.

[broumbroum]

je comprends pas bien le terme classe interne. As-tu un Observer pour chaque "Observe"? Sinon le code est clair. Tu peux meme supprimer les appels "super" par des appels plus courts: setChanged() et notifyObservers()

[flool]

merci pour avoir déplacé au bon endroit

En fait il y a qu'un seule classe Observer qui en observe plusieurs. Dans ces dernières, j'ai opté pour créer une classe à l'intérieur de la classe qui à cette tete là.
Ma question est de savoir si c'est une bonne solution, ou s'il vaut mieux creer une seule classe sous-classe d'Observable, une sorte de gestionnaire.
Pour résumer, j'ai les classes A,B,C qui implemente ce code et qui sont écoutés par D. N'est il pas mieux de creer une classe E qui soit une sous-classe d'Observable et qui est écouté par D, et à laquelle A,B et C indique qu'elles ont été modifiés.
Je suis pas sur d'etre tres clair

[broumbroum]

c'est une bonne methode. A partir d'une instance vers plusieurs objets tu obtiens un lien "1 <- infini" tres pratique.

[®om]

Tout au début où j'ai appris ce concept d'Observer / Listener, j'utilisais Observer/Observable, car si elles étaient là, ça ne devait pas être pour rien.

Mais à l'utilisation, et quand il y a beaucoup d'évènements différents à observer, cela devient ingérable et pas pratique. De plus, on peut voir que dans toute l'api java, notamment Swing, elles ne sont pas utilisées, au profit du principe des listeners (addMachinListener...).

Si tu veux j'ai écrit un tuto sur la création de listeners:
http://rom.developpez.com/java-listeners

[flool]

@ broumbroum : C'est laquelle de solution que tu trouves bien? la classe interne Observe ou la classe gestionnaire?

@ ®om : je m'en vais lire ça tout de suite

[broumbroum]

@ broumbroum : la classe interne en fait

[flool]

Merci. Je vais essayer avec ta méthode ®om, pour voir si cela marchera bien dans mon cas.

[g0up1l]

Attention : les classes de type "Ecouteur" ne remplissent pas le même rôle que les "Observeur".

pour faire simple :

-tes panels ( ou autres éléments IHM ) sont à la fois des écouteurs qui réagissent aux évènements utilisateurs ( click, scroll...) et à la fois des Observeurs qui rendent compte de l'état du Document ( ou Métier ou Modèle ).

-tes classes métiers sont observés par tes panels et, en ce sens, implémentent l'interface 'Observable'.

Ainsi quand ton IHM reçoit un click souris, elle transmet au Contrôleur qui modifie le Document qui déclenchent le 'notifyObservers'. Les vues reçoivent l'évènement dans la méthode 'update' et se redéssinent.

[flool]

Donc si je comprends bien, l'ihm reçoit un clic de souris, le dit à la partie métier et ensuite cette dernière indique à l'ihm, par un notifyobserver, qu'elle a changée.
Et selon toi, la première communication doit se faire comment? Encore Observer/Observable? EventListener?

[®om]

Attention : les classes de type "Ecouteur" ne remplissent pas le même rôle que les "Observeur".

L'implantation est différente, mais le concept est le meme...

[pofet]

Je rejoins g0up1l sur le principe que écouteurs et observeurs ne sont pas la même chose conceptuellement. Un écouteur est plutôt fait pour intercepter des actions utilisateurs et pas pour regarder ce qui se fait côté métier.

Par conséquent, il ne faut pas les utiliser l'un à la place de l'autre et n'importe quand. Un des risques dans ce cas, c'est qu'une personne qui passera derrière aura du mal à comprendre le code car elle trouvera un écouteur là elle s'attendrait à voir un observeur.

Donc si je comprends bien, l'ihm reçoit un clic de souris, le dit à la partie métier et ensuite cette dernière indique à l'ihm, par un notifyobserver, qu'elle a changée.

L'IHM reçoit un clic de souris, elle en parle à un contrôleur qui transmettra comme au différentes classes métier, et qui elles indiqueront à l'IHM via les notifyObserver qu'elles ont changé.
Parfois (souvent ?), le contrôleur ne fait que transmettre directement à un objet métier. On peut alors être tenté de contacter directement l'objet métier depuis l'IHM. Mais soit on applique MVC à la lettre, soit on ne l'applique pas. Car il y a toujours le même problème, si quelqu'un passe derrière, il aura du mal à comprendre un code qui est écrit différemment de ce qu'il devrait être. Sans parler des problèmes éventuels de maintenance...

[bassim]

On peut alors être tenté de contacter directement l'objet métier depuis l'IHM. Mais soit on applique MVC à la lettre, soit on ne l'applique pas

sauf si on fusionne la vue avec le controleur du genre M(VC)

[®om]

La classe Observable et l'interface Observer sont totalement inutilisable en pratique s'il y a plein de choses à écouter... Avec des arguments Observable et Object, on est obligé de tester tous les cas (et de faire les cast) dans les Observers... Et on peut ajouter des Observers à des objets pas du tout prévus pour les évènements qui seront déclenchés (aucune autre vérication de type que Observer).