Créer son propre listener

Bonjour à tous,
J'ai un petit soucis de compréhension sur l'implémentation de son propre listener, j'ai bien sûr lu le cours de Romain Vimont dans les tutoriels.
A travers l'architecture MVC, il met en oeuvre le design pattern Observer à travers son exemple sur la météo. Le principe est que le modèle peut agir sur la vue sans que ces deux éléments se connaissent pas.
Ce que je ne comprends pas, dans son exemple sur la météo, dans la classe qui contrôle la vue, c'est qu'il déclare un objet météo, et de ce fait qu'il ajoute cet objet aux écouteurs par :

Code:

---

meteo.addTemperatureListener(this)

---

Le principe de ce pattern n'est pas justement de ne pas déclarer d'objet concernant le modèle dans la classe contrôlant la vue ??

Je ne sais pas si je suis très clair ...

Salut,


Je suppose qu'il s'agit de ce tutoriel : Créer ses propres listeners en java

Mais je n'y retrouve pas le code que tu indiques :aie:

Citation:

---

Envoyé par womannosky

Code:

---

meteo.addTemperatureListener(this)

---

Le principe de ce pattern n'est pas justement de ne pas déclarer d'objet concernant le modèle dans la classe contrôlant la vue ??

---

Oui et non : le principe est surtout de ne pas les lier "fortement".
Il n'est pas rare que le modèle soit intégré dans la vue pour des raisons de simplification. Après tout la vue a besoin du modèle.


Le principal à mon avis étant de bien séparé les deux du point de vue logique :
Ici la classe Meteo utilise des TemperatureListener et c'est tout. Elle n'a que faire du type réel et de la manière dont seront utilisé les données.

Ainsi si demain tu as besoin de surveiller la météo dans une autre classes quelconque, tu pourras le faire simplement en implémentant un nouveau listener...


a++

Citation:

---

Envoyé par adiGuba

Je suppose qu'il s'agit de ce tutoriel : Créer ses propres listeners en java

---

C'est bien de ce tutoriel oui.

Ok, je vois. C'est juste pour rendre les classes les plus indépendantes possibles.

Donc, si l'on crée un objet Vue, on aura toujours besoin de lui passer en paramètre de son constructeur l'objet modèle ?
Ca créé un peu le bordel dans la classe qui gère la Vue aussi, non ?

Merci pour ta réponse.

Le pattern observer définit un modèle/sujet unique et des observateurs/Views qui vont se déclarer d'une façon ou d'une autre au modèle pour que les mises à jour soient propagées.

Les variations sont dans le "d'une façon ou d'une autre", est ce que le sujet 'pousse' les mises à jour (et comment on interface les "Views" avec le modèle) ou est-ce que la View tire les mises à jour (et comment s'interfacent les Views avec le modèle).

Sans que "View" et "Modèle" aient une connaissance "forte" de leurs structures internes respectives, il faut bien qu'ils coopèrent pour transférer les nouvelles valeurs (ce qui a changé et motive la mise à jour des Views).

Le tutoriel (me) semble proposer une méthode "pousser" avec l'utilisation de la classe EventListener qui facilite l'interfaçage entre Views et Modèle.
- W

Façon élégante de répondre à ma question par oui.
Mais dans ce cas, ça créé un peu le bazard dans la classe qui gère la Vue... :(

Citation:

---

Envoyé par womannosky

Mais dans ce cas, ça créé un peu le bazard dans la classe qui gère la Vue... :(

---

Pourquoi ?


a++

Je te donne un exemple qui peut engendrer un certain bazard dans le code.
Si jamais ton modèle est géré par plusieurs classes, ce qui est souvent le cas je présume. Tu crées tes objets qui gèrent le Modèle dans ton main, tu dois tous les passer en argument dans ton constructeur de la classe qui gère la Vue (par exemple une JFrame) si jamais ils ont tous besoin d'être modifiés.
Par exemple, pour un Jeu de dames, imaginons le Modèle géré par une classe Damier, une classe ListeDesCoupsJoues..., quand tu réinitialises la partie (ton damier à l'écran) à l'aide d'un bouton, la Vue a besoin de connaitre un objet Damier, un objet ListeDesCoupsJoues... pour les réinitialiser.

Que se passe-t-il si le modèle est géré par 5 ou 6 classes ? Il faut passer les 5 ou 6 objets dans le constructeur de la classe qui gère la Vue ?
C'est la seule solution que je vois, ou alors, pense-tu que l'architecture de l'application est mal faite au départ ?

Citation:

---

Envoyé par womannosky

Je te donne un exemple qui peut engendrer un certain bazard dans le code.
Si jamais ton modèle est géré par plusieurs classes, ce qui est souvent le cas je présume. Tu crées tes objets qui gèrent le Modèle dans ton main, tu dois tous les passer en argument dans ton constructeur de la classe qui gère la Vue (par exemple une JFrame) si jamais ils ont tous besoin d'être modifiés.

---

Quelque part nous avons une relation many-to-one entre Views et Modèle.
Si par principe on impose que le Modèle ne connait pas les "Views", ce sont les Views qui vont s'enregistrer au Modèle.
Et puisque le Modèle est "one" dans la relation, il pourrait tout à fait être anchré par un "Singleton".

Citation:

---

Envoyé par womannosky

Par exemple, pour un Jeu de dames, imaginons le Modèle géré par une classe Damier, une classe ListeDesCoupsJoues..., quand tu réinitialises la partie (ton damier à l'écran) à l'aide d'un bouton, la Vue a besoin de connaitre un objet Damier, un objet ListeDesCoupsJoues... pour les réinitialiser.

---

Le bouton va être géré par le Contrôleur qui va s'interfacer avec le Modèle pour créer la situation initiale. Comme le "jeu" change ses représentations aussi donc, on active la mise à jour des Views.

Citation:

---

Envoyé par womannosky

Que se passe-t-il si le modèle est géré par 5 ou 6 classes ? Il faut passer les 5 ou 6 objets dans le constructeur de la classe qui gère la Vue ?
C'est la seule solution que je vois, ou alors, pense-tu que l'architecture de l'application est mal faite au départ ?

---

Séparons View et Modèle en entités "indépendantes".
La View a besoin d'informations sur l'état du Modèle pour afficher la représentation "courante" (mise à jour). Si le Modèle est un "composite", il serait peut être sage que la View passe par un Adapter qui lui permette de récupérer les informations qu'il souhaite en limitant sa connaissance de l'implémentation du Modèle.

- W

Tu réponds pas vraiment à mes questions... :(

J'essaie de dire que l'architecture de l'application mériterait quelques coups de tourne-vis pour coller au modèle MVC.
Ceci dit, votre application n'a pas besoin d'être cohérente avec ce modèle pour fonctionner...
- W

Ok, merci pour ta réponse, c'est vrai que l'application de cette architecture n'est pas indispensable au bon fonctionnement du programme mais ca parait peu propre, donc voilà.

Merci à tous !
Ciao.