MVC et update(Observable S, Object o)

Version imprimable

12/05/2011, 11h17
joejoe1

MVC et update(Observable S, Object o)
Bonjour à tous!

voila mon soucis: je dois concevoir une application ("jtunes") qui est un lecteur de musique mp3
voila à quoi ressemble l'appli (tout n'est pas implémenté) :
http://i26.servimg.com/u/f26/12/16/41/04/scr110.png
mini legende:
1 -> Jlist qui liste les fichiers au format mp3 du fichier séléctionné
2 -> JTable qui listera la playlist actuelle
3 -> les boutons de lecture etc...

mon appli respecte donc le pattern MVC (enfin j'essai;))

pour résumer j'ai donc:
- une vue (PlayerView.java que vous voyez)
- un controller
- un modele

le modele contient TOUTES les données necessaires au fonctionnement de l'appli dans un seul fichier model.java.

Mon probleme c'est que lorsque le modele change d'etat et notifie les observateurs:
Code:

1 2 3 4 setChanged(); notifyObservers(o); clearChanged();
ma vue va appeler la methode update() ce qui aura pour effet de mettre à jours TOUS les JComponents.

vous vous en doutez je voudrais éviter cela et pouvoir ne mettre a jour que ce qui est necessaire.

- j'avais comme 1ere solution de rajouter à toutes les methodes un argument Object arg qui serait le JComponent responsable de l'appel mais j'ai l'impression que ce serait du "bidouillage"

- en 2 je voulais créer 3 modeles différents (et donc 3 controllers) mais je me dis que le pattern observer étant une relation d'un modele à plusieurs vues, cela reviendrait à faire exactement l'inverse...

Pourriez vous me donner la meilleure solution pour avoir une MAJ efficace?
je pense que le probleme est simple a resoudre mais jusque la le modele de mes applis etait plus simple et je n'avait pas encore été confronté à ce soucis...

Merci d'avance pour vos réponses:ccool:
12/05/2011, 12h03
hegros

Tes 2 solutions me semblent bien avec une préférence pour la seconde solution parce que la contrainte un modèle plusieurs vues je ne sais pas d'où tu sors cela surtout si chaque vue à une fonction différente tu vas forcément avoir un modèle différent.
12/05/2011, 13h39
joejoe1

J'avoue qu'entre les deux la solution 2 me semblait la meilleure mais il se pose d'autres soucis si je procede ainsi:

- chaque vue n'ayant qu'un unique controller, il faudrait dans ce cas que je "split" ma classe ViewPlayer.java en 3 vues distinctes pour les reunir ensuite dans une JFrame...a la limite pourquoi pas encore que ca ne me semble pas des masses logique.

- de plus, et c'est ce qui me gene le plus:
3 modeles différents me gênent un peu car ils devront interagir... du coup je ne vois pas la raison de les séparer...

je veux dire si je fais:
-model1 : s'occupe des données de la liste de recherche dynamique(accés en BDD(sqlite) etc)
-model2 : s'occupe des ajouts de morceaux et donc de la playList (JTable)
- model3 : s'occupe de tout ce qui a atrait à la lecture

dans ce cas le model2 devra faire appel aux données du 1 pour rajouter un certain morceau

et le 3 faire appel à celles du 2 pour lancer le bon morceau suivant la playlist...

du coup un tel decoupage ne me semble pas logique!
12/05/2011, 13h51
hegros

Citation:

Envoyé par joejoe1

- chaque vue n'ayant qu'un unique controller,

Non tu peux avoir un contrôleur pour ta vue mais avec 3 abonnements d'observateurs.

Ton problème c'est que tu donnes la responsabilité à la vue de dire quoi mettre à jour alors qu'elle ne devrait s'occuper que de la mise à jour. Ce que je veux dire c'est que c'est au contrôleur d'appeler la bonne méthode d'update en fonction de ce qui a changé dans le modèle.

Dans le notifyobserver tu devrais faire par exemple :

S'il y a un ajout de morceau alors ton contrôleur devrait faire

ViewPlayer.UpdatePlayList();

S'il s'agit d'une mise à jour de la lecture alors ton contrôleur devrait faire

ViewPlayer.UpdatePlayInProgress();

Citation:

- de plus, et c'est ce qui me gene le plus:
3 modeles différents me gênent un peu car ils devront interagir... du coup je ne vois pas la raison de les séparer...

je veux dire si je fais:
-model1 : s'occupe des données de la liste de recherche dynamique(accés en BDD(sqlite) etc)
-model2 : s'occupe des ajouts de morceaux et donc de la playList (JTable)
- model3 : s'occupe de tout ce qui a atrait à la lecture

dans ce cas le model2 devra faire appel aux données du 1 pour rajouter un certain morceau

et le 3 faire appel à celles du 2 pour lancer le bon morceau suivant la playlist...

du coup un tel decoupage ne me semble pas logique!

En principe tu devrais avoir 1 fichier ou 1 classe par modèle. Et qu'il y ait des dépendances dans le package modèle est tout à faire normal et logique.
12/05/2011, 14h13
joejoe1

Citation:

En principe tu devrais avoir 1 fichier ou 1 classe par modèle. Et qu'il y ait des dépendances dans le package modèle est tout à faire normal et logique.

c'est justement ma question^^
en fait pour le moment toutes les données sont regroupées dans le meme fichier JtunesModel.java .
il faudrait donc que je separe mes données en 3 modeles differents?

Citation:

Non tu peux avoir un contrôleur pour ta vue mais avec 3 abonnements d'observateurs.

jaime assez cette idée! j'aurais donc
1 seule vue
1 seul controller
3 modeles

c'est bien ca?

Citation:

Dans le notifyobserver tu devrais faire par exemple :
S'il y a un ajout de morceau alors ton contrôleur devrait faire
ViewPlayer.UpdatePlayList();

ici par contre je ne comprend pas bien ou tu veux en venir, la notifications des observers se fait bien dans le model avec setChanged() + notifyObservers() non?

parcequ'en réalité tout le problème se situe la:
pour le moment,mon modele possède les données concernant la Jlist de recherche(numero1 du graphique) de la JTable playlist(numero2) et du lecteur a proprement parler(numero3)

et quand le modele fait appel a setChanged() + notifyObservers() il envoi a ma vue un unique signal pour dire que son état a changé mais sans preciser quelle partie...et c'est le drame :aie:

Citation:

Envoyé par joejoe1

c'est justement ma question^^
en fait pour le moment toutes les données sont regroupées dans le meme fichier JtunesModel.java .
il faudrait donc que je separe mes données en 3 modeles differents?

Clairement oui.

Citation:

Envoyé par joejoe1

jaime assez cette idée! j'aurais donc
1 seule vue
1 seul controller
3 modeles

c'est bien ca?

Oui quoique tu peux aussi découper en 3 vues cela peut être utile dans une optique de ré utilisabilité.

Citation:

Envoyé par joejoe1

ici par contre je ne comprend pas bien ou tu veux en venir, la notifications des observers se fait bien dans le model avec setChanged() + notifyObservers() non?

parcequ'en réalité tout le problème se situe la:
pour le moment,mon modele possède les données concernant la Jlist de recherche(numero1 du graphique) de la JTable playlist(numero2) et du lecteur a proprement parler(numero3)

et quand le modele fait appel a setChanged() + notifyObservers() il envoi a ma vue un unique signal pour dire que son état a changé mais sans preciser quelle partie...et c'est le drame :aie:

La question est justement qu'est-ce que tu fais dans ton NotifyObserver ? Tu es sensé appeler une méthode de l'observateur non ?

Et ton idée de passer des arguments aussi est correcte, en gros voilà à quoi je pense niveau code à toi de l'adapter en ajoutant les autres abonnements avec les paramètres dont tu as besoin, c'est juste pour que tu comprends mon idée
Code:

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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 interface IViewPlayer { public void UpdatePlayList(List<string> NewPlayList); } class ControllerViewPlayer { IViewPlayer ViewPlayer; List<IViewPlayer> observersPlayList = new List<IViewPlayer>(); public ControllerViewPlayer(IViewPlayer player) { ViewPlayer = player; } public void AddObserverPlayList(IViewPlayer observer) { observersPlayList.Add(observer); } private void NotifyPlayList(Modele model) { foreach(IViewPlayer player in observersPlayList) { player.UpdatePlayList(model.GetPlayList()); } } public void AddPlayList(string Repertoire) { //instanciation du modèle etc.... NotifyPlayList( new Model(Repertoire)); } } class ViewPlayer : IViewPlayer { ControllerViewPlayer _Controller; public ViewPlayer() { _Controller = new ControllerViewPlayer(this); _Controller.AddObserverPlayList(this); } public void UpdatePlayList(List<string> NewPlayList) { //mise à jour du composant graphique de la playlist} } public void ClicAddPlayList() { _Controller.AddPlayList(NomRepertoire); }

pour moi ce n'est pas au controller de notifier les vues, c'est au modele... Je me trompe?
perso je fais un truc du genre:
dans le model

Code:

1
2
3
4
5
6
7
8
9
public void addMorceau(String[] ts){
		Morceau temp = new Morceau(ts[0], ts[1], ts[2], ts[3], ts[4] );
		this.playListData.add(temp);
		
		setChanged();
		notifyObservers();
		clearChanged();
}

et dans la vue j'ai la methode:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public void update(Observable s, Object o) {
		//TODO
		
		majSearchList();
		majPlayList();
		
}
public void majSearchList(){
		clear(searchList);
		DefaultTableModel defMod = (DefaultTableModel) searchList.getModel();
		for (Morceau m : model.getSearchListData()) {
			String[] vec = {m.getTitre(), m.getArtiste(), m.getAlbum(), m.getGenre(), m.getYear()};
			defMod.addRow(vec);
		}
	}
	
public void majPlayList(){
		clear(playList);
		DefaultTableModel defMod = (DefaultTableModel) playList.getModel();
		for (Morceau m : model.getPlayListData()) {
			String[] vec = {m.getTitre(), m.getArtiste(), m.getAlbum(), m.getGenre(), m.getYear()};
			defMod.addRow(vec);
		}
	}

13/05/2011, 10h51
hegros

Citation:

Envoyé par joejoe1

pour moi ce n'est pas au controller de notifier les vues, c'est au modele... Je me trompe?

Il existe plusieurs variantes du MVC.

Tes vues peuvent s'abonner directement à tes modèles (dans ce cas passe par des interfaces pour inverser les dépendances sinon tu casses le principe du pattern en donnant une dépendance de ta vue vers ton modèle plutôt que l'inverse) ou alors tes vues peuvent s'abonner à ton contrôleur qui lui même s'abonnera à tes modèles et dans ce cas tu n'as pas de dépendance entre vue et modèle c'est totalement découplé.

Pour la notification, dans le premier cas c'est ton modèle qui va notifier tes vues et dans la second c'est ton modèle qui va notifier ton contrôleur qui lui même va notifier tes vues.

Dans le premier cas on ne voit plus l’intérêt du contrôleur donc j'ai une préférence pour le second cas car cela permet de faire plus de chose, parce que dans ton NotifyObservers dans ton modèle tu fais quoi tu appelles bien une méthode de la vue non ?

C'est dommage que tu ne montres pas le code d'abonnement de la vue au modèle et que tu ne montres pas à quoi te sert ton contrôleur pour le coup.

Ce qui est dommage aussi c'est que à priori avec ce code tu ne résouts pas ton problème de départ, tu es toujours obligé de mettre à jour tous tes composants graphiques alors que tu as juste ajouté un morceau

je ne savais pas qu'il y avait deux variantes!

j'utilise celle qui est notamment décrite dans le livre "Tete la 1ere Design Pattern"

donc oui c'est ma/mes vue(s) qui s'abonne(nt) au modele voila mon code:
Code:

1 2 3 4 5 6 7 8 public ViewPlayer( InterfaceJTunesController controller, InterfaceJTunesModel model ) { this.setLayout(new BoxLayout(this, BoxLayout.Y_AXIS)); this.model = model; this.controller = controller; ((Observable) model).addObserver(this); //connexion vue/model }
d'ou le soucis car JE ne fais rien dans la methode notifyObservers tout simplement parceque je n'en écrit pas!

En fait, mon modele étend la classe Observable qui possede une methode notifyObservers() que j'utilise.

l'etape d'aprés c'est la méthode update(Observable s, Object o) qui est lancée par ma vue pour se mettre à jour..

voila ce que je pense faire suite a notre "conversation":
- couper mon modele en 3
- dans la methode update(Observable s, Object o) de ma vue : faire un test sur la classe de s pour savoir ce qui a changé et donc quoi mettre à jour
du coup pour ma vue cela donnerait:
Code:

1 2 3 4 5 6 7 8 9 10 11 public ViewPlayer( InterfaceJTunesController controller, InterfaceJTunesModel model, InterfaceModel2 mod2, InterfaceModel3 mod3 ) { this.setLayout(new BoxLayout(this, BoxLayout.Y_AXIS)); this.model = model; this.model2 = mod2; this.model3 = mod3; this.controller = controller; ((Observable) model).addObserver(this); //connexion vue/model ((Observable) model2).addObserver(this); ((Observable) model3).addObserver(this); }
PS: j'ai aussi retenu que pour la réutilisabilité il vaufrait mieux que je coupe ma vue en 3 seulement je ne suis pas sur d'avoir le temps de recoder tout ca sachant que je dois bientot rendre le projet et qu'il me reste encore pas mal de boulot
-------------------------------------------------------------------------------------

PS: pour ma part , voila comment le MVC que jutilise(celui que j'ai appris) fonctionne:

1 - l'utilisateur agit sur l'IHM(vue)
2 - la vue passe linfo au controller (ex: a l'appui d'un bouton, ajouter un morceau)
3 - le controller renvoie l'info au modele(ex : model.addMorceau() )
4 - le modele se met a jour et signal à ses abonnés qu'il a changé (methodes setChanged() + notifyObservers() )
5 - la vue se met a jour grace à sa methode update (car elle implemente Observer)

J'aimerais beaucoup apprendre "ta" maniere de faire ou le controller semble avoir plus de controle (lol) sur l'appli

pourrais tu me donner un lien vers un tuto qui traite le MVC de cette maniere ou un livre svp?

13/05/2011, 14h53
hegros

1 pièce(s) jointe(s)

Citation:

Envoyé par joejoe1

je ne savais pas qu'il y avait deux variantes!

Pas 2 mais plusieurs (dans Tête la première Design Pattern il me semble que 2 sont nommées), c'est surtout au niveau du couplage que cela change. Regarde bien dans le livre les dépendances entre Vue/Contrôleur/Modèle et les différentes variantes.

Pour te faire comprendre la différence, j'ai fais 2 schémas d'architecture qui montrent les différences de couplage entre ton implémentation et la mienne. Encore que je n'ai pas une vision complète de ton implémentation

Je ne sais pas par exemple si le 'this' que tu passes à la méthode Observer de ton modèle depuis la vue est une interface ou pas.

Au final, c'est quasiment la même à quelques détails près :)

En fait, ce qui me gêne le plus entre la dépendance modèle-> vue que tu as, c'est que le modèle c'est potentiellement une base de données (donc des objets DAO) ou un équipement (matériel), et cela me choque un peu qu'une base de données (ou un objet DAO)fasse appel à une IHM. Je préfère garder le contrôle de cet appel dans un contrôleur (imagine par exemple que tu communique par WebService avec ton IHM pour la mettre à jour)
13/05/2011, 17h12
joejoe1

Je crois que j'ai une vision encore un peu floue du pattern MVC mais ca me parait evident que la seconde maniere de proceder permet un couplage plus faible.

Sinon j'ai rejeté un oeil au livre "design pattern tete la 1ere" mais je ne vois qu'une maniere de mettre en oeuvre le MVC proposée ='(. (sur un exemple de controleur de tempo et de gestion des BPM (battements /mn))

Je crois que ce qui m'a pérturbé lors de la conception en 1er lieu c'est le fait que jusque la je n'avais qu'a représenter un même modele de manieres differentes à l'aide de differentes vues.

Alors que la mes vues ne font que représenter des parties du modele mais comme les données d'une partie sont necessaires à au moins l'une des deux autres

du coup j'ai peine a faire coller le schema tres simple a comprendre:

Citation:

vue---->controller---->modele-
^_____________________l

petite question en espérant ne pas passer pour un idiot^^ :

en parcourant les forums et les tutos a propos de MVC j'ai notamment entendu parler de sa variante dédiée aux Web Services et appelée "Modele2" pour MVC2 en fait...

ne serait ce pas justement la version dont tu me parles?
auquel cas je m'attaquerais au tuto.

en tout cas je te remercie pour toute l'aide que tu m'as apportée! :ccool:

PS: qu'as tu utilisé comme logiciel pour faire les schémas? ca me rappel un plugin eclipse qui permettait de faire un diagramme UML depuis le code d'un projet mais j'ai oublié le nom de ce plugin...
13/05/2011, 20h09
hegros

Citation:

Envoyé par joejoe1

Sinon j'ai rejeté un oeil au livre "design pattern tete la 1ere" mais je ne vois qu'une maniere de mettre en oeuvre le MVC proposée ='(. (sur un exemple de controleur de tempo et de gestion des BPM (battements /mn))

Je rejetterais un coup d'oeil sur le livre car de mémoire il parlait d'au moins une autre variante (peut-être sans le schéma mais juste dis de manière textuel)

Citation:

en parcourant les forums et les tutos a propos de MVC j'ai notamment entendu parler de sa variante dédiée aux Web Services et appelée "Modele2" pour MVC2 en fait...

Peut-être, j'en ai entendu parler sans vraiment regarder. C'est peut-être encore une autre variante pour le web

Citation:

PS: qu'as tu utilisé comme logiciel pour faire les schémas? ca me rappel un plugin eclipse qui permettait de faire un diagramme UML depuis le code d'un projet mais j'ai oublié le nom de ce plugin...

Le logiciel s'appelle Bouml. On a la chance en plus d'avoir un sous-forum dédié à cet outil et d'avoir son auteur qui contribue souvent sur le forum UML.