Discussion :

[womannosky]

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 :

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

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 ...

[adiGuba]

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

Code :

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

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++

[womannosky]

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.

[wiztricks]

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

[womannosky]

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...

[adiGuba]

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

Pourquoi ?


a++

[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.
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 ?