Discussion :

[rp37000]

Bonjour à tous et à toutes,


J'essaye de me faire une petite synthèse de ce que je crois avoir compris
du MODELE MVC standard, pourriez-vous me dire si j'ai bien compris, si ce que je dis est juste , si je n'oublie rien,
MERCI beaucoup pour votre aide et vos critiques .



LES ROLES:

- LE MODELE:

. Représenter et encapsuler les données d'une LOGIQUE METIER et offrir
à l'extérieur des moyens de lire et d'en modifier certaines.


- LA VUE:

. Permettre à l'utilisateur d'avoir une représentation VISUELLE du
MODELE ou d'une partie du MODELE, la plus à jour possible.
Une VUE est donc spécifique à un MODELE donné.

.Permettre à l'utilisateur d'interagir avec le MODELE
(Demandes de: modif, ajout, suppr, visu)


- LE CONTROLEUR:

. Recevoir les Demandes de l'utilisateur que lui transmet donc la VUE, les
interpréter vis-à-vis du MODELE, les filtrer, les contrôler.

. Demander au MODELE de se mettre à jour (modif, ajout, suppr).

. Implémenter la LOGIQUE graphique de la VUE: griser tel widget si tel autre
... .



MISE EN OEUVRE


- LE MODELE:

. Le MODELE est observable directement par une ou plusieurs
VUES. Dans les faits, les VUES sont les seules observatrices du MODELE.

. Le MODELE sait qu'il peut avoir des observateurs pour chacune de ses
propriétés. Il gère donc une liste d'observateurs par propriété X qu'il
possède(et souhaite rendre lisible), il possède donc autant de méthodes :
.notifyObservers_DeLaProprieteX()
.addObserver_DeLaProprieteX( IObserver_ProprieteX objet)
.removeObserver_DeLaProprieteX( IObserver_ProprieteX objet)
.Les observateurs d'une propriété X devront s'enregistrer en tant que tel
auprès du MODELE en faisant un appel du syle:
this.modele.addObserver_DeLaProprieteX( this ).
Et ces observateurs-ci devront donc implémenter une interface
IObserver_ProprieteX contenant une méthode
updateWidget_PourLaProprieteX(), que la méthode
notifyObservers_DeLaProprieteX() du MODELE pourra alors appeler
pour leur signifier le changement de sa ProprieteX.


.Le MODELE implémente une interface genre IModele_get contenant des
méthodes de lecture du MODELE (get()), permettant ainsi à un
observateur de l'interroger, par exemple:
(vue.widgetPourProprieteX.value=vue.modele.getProprieteX()...)

.Le MODELE implémente une interface genre IModele_set contenant des
méthodes d'écriture sur le MODELE (add(), set(), del()),
permettant ainsi au CONTROLEUR(uniquement) de
pouvoir le modifier directement.


- LA VUE:

.La VUE sait mettre à jour toute seule ses champs par simple appel
direct des méthodes get() que le MODELE met à disposition de ses
observateurs (le modele implémentant IModele_get).
La VUE voit le MODELE uniquement comme étant de type IModele_get.
La VUE ne peut ainsi que CONSULTER le MODELE (pas de modif!).
La VUE se met à jour, soit pour initialiser le contenu de ses champs,
soit sous sollicitation du MODELE qui l'informe d'un changement des
données qui la concerne (et donc pour lesquelles la VUE s'était enregistrée
en tant qu'observatrice).
.La VUE implémente une interface IObserver_ProprieteX pour chaque
propriété X du MODELE qu'elle souhaite observer.
La VUE possède donc une méthode updateWidget_PourLaProprieteX()
que son MODELE invoquera pour signifier le changement de la propriété X.
Mais la VUE peut elle même, au moment de l'initialisation de ses champs,
faire appel à sa méthode updateWidget_PourLaProprieteX() pour initialiser
la valeur contenu dans le Widget représentant visuellement la propriété X.

.La VUE connait le CONTROLEUR, et pour elle le CONTROLEUR est de
type IController (interface que devra implémenter le CONTROLEUR
concret). Cette interface contient des méthodes que la VUE invoquera
suite à une action de l'utilisateur. La VUE pourra ainsi dire à SON
CONTROLEUR que l'utilisateur demande telle modif. sur le MODELE:
this.controller.demandeModif_ProprieteX().

.La VUE peut également implémenter une interface IVUE
qui permettra à son CONTROLEUR de la mettre à jour d'un point de vue
LOGIQUE graphique: griser , rendre (in)visible, tel widget, etc... .
Ainsi le VUE pourra par exemple posséder une méthode
setWidget1_visibility(boolean).



- LE CONTROLEUR:

. Implémente une interface IController, permettant d'offrir des méthodes
à la VUE pour qu'elle puisse transmettre au CONTROLEUR les demandes
de l'utilisateur.

. Pour le CONTROLEUR, la VUE est de type IVUE, à savoir elle implémente
l'interface IVUE, il peut donc agir sur la LOGIQUE graphique de cette
dernière: par exemple, this.vue.setWidget1_color( errorColor ) .

. Pour le CONTROLEUR, le MODELE est de type IModele_set, à savoir que
ce dernier implémente IModele_set (un ensemble de méthodes que le
MODELE met à dispo. pour qu'on puisse le mettre à jour).
Le CONTROLEUR peut donc ordonner des modifs sur le MODELE:
this.modele.setProprieteX( newValue ) .

. Le CONTROLEUR n'a pas besoin de lire le MODELE ....?
Il se contente juste de le mettre à jour car c'est la VUE qui interrogera
le MODELE .


Voilà j'espère que je n'ai rien oublié de ce que j'en pense .



MERCI beaucoup pour votre participation, vos remarques et critiques.

[rp37000]

Et un petit diagramme de classes pour résumer.

[tristan_m]

Bonjour,

D'abord bravo pour ce travail de synthèse, c'est pas forcément évident d'appréhender tout un système de cette façon.

Pour répondre à ton message, je n'aborderais pas trop l'implémentation car je pense que c'est plus au développeur de décider ce qu'il y a de plus simple/maintenable/rapide à réaliser selon les critère extérieurs (environnement de développement, client impatient, etc...).

En revanche j'ai noté deux trois points qui sont à appronfondir si l'on souhaite respecter le modèle MVC scrupuleusement.
D'abord une doc. que j'aime citer en référence :
http://java.sun.com/blueprints/patte...-detailed.html

Le premier je pense, c'est plus un problème de description je pense :

Une VUE est donc spécifique à un MODELE donné.

Il est évident que les interfaces modèle et vue doivent être cohérentes. On ne vas pas poser une vue d'une horloge digitale sur un modèle d'un lecteur multimédia .
En revanche, le principe de MVC est de pouvoir changer de modèle /vue / controleur sans que les autres composants soient impactés. Donc plusieurs modèles peuvent correspondre à une seule vue, si tant est que les interfaces correspondent.


Le deuxième point est peut être discutable également. Dans le diagramme, je vois que la vue possède une instance du modèle. Même si la vue n'a accès qu'à des propriété "get", en principe ce ne devrait pas être le cas.

Dans ce que j'ai compris du pattern observateur, c'est l'objet observé qui notifie ses observateurs qu'il y a eu une modification. C'est donc l'objet observé qui possède des références vers ses observateurs, et pas l'inverse.



Enfin, à propos du contrôleur, je ne suis pas sur du tout d'avoir raison mais j'ai une vision différente de son fonctionnement.

Pour le CONTROLEUR, la VUE est de type IVUE, à savoir elle implémente
l'interface IVUE, il peut donc agir sur la LOGIQUE graphique de cette
dernière: par exemple, this.vue.setWidget1_color( errorColor ) .

Ce point est TRES discutable, mais dans le principe, Le contrôleur ne peut que décider de changer de vue. Pour reprendre l'exemple de la montre, c'est au contrôleur de décider si on passe d'une vue horloge digitale à une vue horloge à aiguille. En revanche au sein de la vue, il ne doit pas avoir d'influence. La théorie voudrait alors qu'il y ait une vue spécifique avec le bouton grisé...

. Le CONTROLEUR n'a pas besoin de lire le MODELE ....?
Il se contente juste de le mettre à jour car c'est la VUE qui interrogera
le MODELE .

Le contrôleur n'a pas besoin de lire le modèle : oui.
J'aurais même envie de dire : il ne DOIT pas.

Par contre, comme dit sur le point 2, ce n'est pas la vue(observateur) qui va interroger le modèle (observé). Normalement la vue ne doit pas connaître le modèle.
Lorsque le modèle notifie à la vue qu'un changement s'est produit, alors la vue va demander au modèle (passé en argument) quelles sont les modifications produites, et se mettre à jour en conséquence.


Voilà, encore une fois j'ai peut être tort sur ce que j'ai énoncé, en tout cas c'est ce que j'ai compris de MVC.
N'hésite pas si tu as des questions supplémentaires sur des points que j'aurais mal expliqués.

Bon courage!

[rp37000]

Bonjour tristan m,


Merci beaucoup d'avoir pris du temps pour venir enrichir cette discussion et partager tes perceptions et ton expérience.

Le lien que tu me proposes , résume bien ce que de mon côté j'avais saisi sur le MVC.


Pour ta part, tu me dis:
"plusieurs modèles peuvent correspondre à une seule vue, si tant est que les interfaces correspondent."

Je suis d'accord avec cela, disons, dans le cas d'une vue plus généraliste permettant donc de représenter visuellement des modèles différents. Auquel cas on aurait à faire à une vue paramétrable (les libellés métiers notamment).
Je ne crois pas pourtant qu'il s'agisse du cas le plus fréquent, mais idéalement ce serait effectivement top d'avoir un minimum de vues utilisables pour un max de modèles!! Je pense qu'on resterait malgré tout sur du MVC.


A propos du pattern observateur, tu me dis:
"...C'est donc l'objet observé qui possède des références vers ses observateurs, et pas l'inverse."
Effectivement l'observé (le modèle) contient des références vers ses observateurs (vues) et le modèle sait juste
que ses observateurs implémentent une certaine interface (dans mon exemple: IObserver_proprieteX, IObserver...Y, ...),
il se fiche en effet de connaître le type concret de ses observateurs. Donc là on est d'accord.
PAR CONTRE, concernant le fait que l'observateur n'est pas de référence vers son sujet observé, il est plus que possible qu'au contraire il en possède une (passée à son constructeur).
Et là je m'appuie sur ce que j'ai lu dans 3 bouquins:
-"Design patterns tête la première": page 68.
-"Design pattern les 23 modèles de conception" de DEBRAUWER: page 248.
-"Design patterns , catalogue de modèles de conception réutilisables" du Gang Of Four: page 345, 353 .

Mais je crois qu'avant tout, en la matière il y a souplesse: on peut rester dans le pattern observateur en faisant:
-Aussi bien ça (cas 1):
l'observateur ne connaît le modèle que ponctuellement par le biais d'un appel de ce dernier, lorsque le modèle fait: this.observers[n].update(this) , il se transmet lui-même en param. à l'observateur,
qui lui, implémente la méthode update(IModele), laquelle attend pour type un IModele (IModele_get dans mon exemple).
Auquel cas l'observateur une fois notifié va faire un: this.monWidget.value=modeleRecuEnParam.getDataSouhaitee() pour
pouvoir récupérer auprès du modele la valeur à imputer à son Widget.

-Que ça (cas 2):
Comme indiqué sur mon Diagramme: l'observateur (vue) possède une(des) référence(s) vers son(ses) sujet(s) (observé(s)).
Il a donc juste à faire un this.monWidget.value=this.modele.getDataSouhaitee() une fois update() appelée.
On remarquera que dans ce cas là, la méthode update() n'a pas de param. (mais ça pourrait... cf. parenthèse ci-dessous).

(Petite parenthèse sur le Pattern Observateur, en passant:
on peut avoir des cas où un observateur observe plusieurs sujets).

Enfin, à propos de l'initialisation du contenu des champs de la Vue:
celle-ci n'est à priori pas initiée(notifiée) par le modèle car au début le modèle ne subit pas forcément un changement d'état que qqch aurait suscité: donc pour son initialisation, la Vue doit être capable de renseigner le contenu de ses champs sans bénéficier de la notification du modele.
Alors dans le cas 1: on peut imaginer que le Contrôleur lui dit : initialise-toi en lui transmettant le modele en param. .
Et dans la cas2: la Vue connaît déjà le modèle donc elle sait se mettre à jour toute seule.

On notera quand même que dans le MVC , l'idée c'est que : c'est la VUE qui, pour pouvoir renseigner ses propres champs, interroge directement le MODELE (modele.getData()). Et que dans le cadre particulier de son initialisation, la Vue interroge le modele sans que celui-ci l'en ait notifié!
Je ne pense pas raconter de bêtises là ( vu dans le bouquin de DEBRAUWER, p. 248).




Concernant le fait que le Contrôleur implémenterait la LOGIQUE de la Vue:
En fait je veux effectivement dire qu'à travers des méthodes de l'interface IVue le Contrôleur demande à la Vue de se modifier, la Vue s'éxécute alors sans broncher, et d'une façon totalement opaque(Swing, AWT,...)
pour le Contrôleur, elle effectue la modif. GRAPHIQUE correspondant à l'ordre du Contrôleur.

Si j'ai bien compris? : toi tu as compris que:
* Un Etat donné d'une Vue de Base => Une Vue différente
* Et que le Contrôleur fait 2 choses:
- Recevoir les demandes que l'utilisateur effectue via les composants de la Vue. (Vue-->Controleur)
- Ordonner les changements de Vue. (Vue<--Controleur)

J'avoue que personnellement je n'adhère pas: ça ferait trop de Vues.
D'après ce que j'ai compris le Contrôleur est le CERVEAU, la LOGIQUE de la Vue, c'est lui qui donne les ordres à celle-ci:
il lui dit via une Interface: "fais ça et tais-toi!" et la Vue fait avec les moyens du bord prévus.
Tu noteras que ça n'enlève en rien le fait que le Contrôleur n'ait pas besoin de savoir comment la Vue s'y prend CONCRETEMENT pour le faire.
L'important je crois et que la Vue et le Contrôleur communiquent via Interface (IController et IVue)
et que la tambouille interne et concrète de chacun ne regarde plus l'autre.

-Un Contrôleur1 concret dira à la Vue1, via l'interface IVue : "Grise ton bouton 'Ajouter'", et la Vue1 grise la bête...
-Un autre contrôleur, Contrôleur2 concret dira à la même Vue1, via l'interface IVue : "Grise ton bouton 'Ajouter'", et la Vue1 grise aussi la bête...
Mais la différence c'est que le Contrôleur1 ne le dira pas forcément pour les mêmes raisons(Trop d'ajouts faits, Heure dépassée,...) que le Contrôleur2:
ce qui varie entre les 2: la LOGIQUE de l'interface graphique, pour une MEME Vue donc!
Pour une Vue donnée, le CONTROLEUR est UNE STRATEGIE(une façon d'implémenter la LOGIQUE de la Vue):
une même VUE => n STRATEGIES <=> n Contrôleurs .
(cf. Pattern STRATEGY).
Enfin voilà là-dessus je pense encore être dans le vrai, sur le bon chemin.
Mais j'avoue que c'est pas facile de définir une frontière ferme et carrée entre ce qui est uniquement du ressort de la Vue et ce qui est uniquement du Ressort du Contrôleur.


Enfin, je reviens sur un point, j'ai dit:
"Le CONTROLEUR n'a pas besoin de lire le MODELE ....?"
et bien je reviens sur cette pseudo-intuition que j'avais, je change mon fusil d'épaule et je dis:
Je pense que le Contrôleur devrait avoir la possibilité(si besoin) d'interroger -(en plus de le mettre à jour)- le modele,
dans certains cas, et pour son propre compte, pour son propre raisonnement interne, MAIS PAS pour mettre directement à jour la Vue on est
bien d'accord, ce serait juste pour nourrir la Stratégie qu'il implémente.


Encore Merci tristan m,
tu soulèves des points qui méritent réflexion et apporte de l'eau au moulin.

[tristan_m]

Bonjour,

J'avoue avoir fait moins de recherche bibliographique sur le sujet, aussi j'aurai vite du mal à soutenir cette discussion.

A propos du pattern observateur, je me suis basé sur le livre du GoF uniquement. L'exemple d'implémentation utilise la cas 1 que tu as décris, donc pas de référence à l'observé dans l'observateur. (stockée tout du moins).

Maintenant c'est vrai qu'il ne s'agit que d'implémentation, la littérature que j'ai pu lire n'étant pas suffisamment claire ou conséquente sur l'intérêt de l'une ou l'autre méthode. En tout cas je serai moins catégorique sur ce point à l'avenir


Au sujet de la vue qui interroge le modèle, l'idée que tout parte du modèle me plait pour au moins une raison : Pas besoin de polling. Il est plus efficace en général d'effectuer une modification sur réception d'un évènement que d'interroger une base tous les deltas de temps pour savoir si une modification a eu lieu.
Aprés bien sur rien n'empêche de faire un système plus intelligent qui saurait faire les deux de façon optimisée.

Quant à l'initialisation, il suffit d'envoyer une notification à l'observateur au moment ou il s'enregistre. La vue est alors automatiquement à jour dés qu'elle est enregistrée comme observateur du modèle.



Pour le controleur, j'y ai repensé et effectivement il y a une autre façon de faire qu'une vue spécifique.
La vue représentant le modèle, c'est le modèle qui doit intégrer la modification (et notifier la vue en cas de changement).
Ca m'embête un peu que le contrôleur puisse changer l'état d'une vue. Comment une autre vue aurait connaissance de ce changement?

Je suis entièrement d'accord sur le fait que le controleur soit une stratégie pour la vue. Le controleur représente la logique du logiciel dans le sens ou c'est lui qui dicte au modèle quelles actions il doit opérer, et si un bouton doit être grisé, c'est au modèle (qui définit les lois de fonctionnement) d'en décider. Je ne pense pas que le contrôleur doive "bypasser" le modèle.

Personnellement je vois plus le contrôleur comme un cablage qui indique quelle action doit être réalisée en fonction de l'évènement reçu par la vue. Typiquement le contrôleur aurait tout bénéfice à être implémenté dans une machine à état, chaque état représentant une stratégie.



Enfin pour le dernier point, je vais faire comme toi et changer mon fusil d'épaule
Bien que ce que j'ai pu lire n'indique jamais ce genre de requête, je ne vois pas comment le contrôleur peut tout maîtriser sans avoir une idée (ou au moins une demande de confirmation) de l'état du modèle. Comment le contrôleur peut savoir si une demande de changement a marché (et éventuellement passer dans un état différent)? si oui quelle est la nature du changement?
Ou alors passer par la vue qui enverra au contrôleur un évènement d'acquittement lors de la notification du modèle........
J'avoue que je ne vois pas ce qui justifierait un système si complexe.


Sinon je tiens également à te remercier de me faire revoir mes affirmations. Ca m'aide aussi à clarifier certains points pas toujours très clairs dans mon esprit (ou clairs mais faux )

[rp37000]

Bonjour tristan_m, et merci pour tes réflexions.


Le pattern observateur évite justement ce fameux:
"interroger le modele tous les deltas de temps pour savoir si une modification a eu lieu". On est bien d'accord.
Et pour l'initialisation de la vue: Merci pour l'idée, je suis preneur.
"il suffit d'envoyer une notification à l'observateur au moment ou il s'enregistre." plutôt que la Vue fasse appel elle-même à sa propre méthode update().



Je ne comprends pas ce qui te gêne EXACTEMENT quand tu dis:
"Ca m'embête un peu que le contrôleur puisse changer l'état d'une vue. Comment une autre vue aurait connaissance de ce changement?"
Et en plus je ne sais pas quoi te répondre??




Tu dis:
"Le controleur représente la logique du logiciel dans le sens ou c'est lui qui dicte au modèle quelles actions il doit opérer, et si un bouton doit être grisé, c'est au modèle (qui définit les lois de fonctionnement) d'en décider. Je ne pense pas que le contrôleur doive 'bypasser' le modèle."
Ben là... , j'adhère carrément pas !

Le modele ne connaît jamais la Vue en tant que Vue mais uniquement en tant qu'objet observateur implémentant une interface (dans mon exemple IObserver_...). Le modèle contient les LOIS de fonctionnement propre au METIER, pas celles de la VUE!! C'est justement le contrôleur qui gère ce dernier point!
A mon sens, le CONTROLEUR ne représente PAS la LOGIQUE du modele, c'est-à-dire qu'il ne représente PAS la LOGIQUE METIER, surtout pas: c'est le MODELE qui intègre cette LOGIQUE METIER, et le CONTROLEUR s'en bat les cacahuètes je pense. Le CONTROLEUR intègre juste la LOGIQUE de L'INTERFACE GRAPHIQUE vis-à-vis des conséquences sur le modele: c'est PAS la même chose. Le modele ne cherche jamais à modifier la Vue, il met juste à disposition des valeurs que pourront venir chercher des observateurs quelconques lorsqu'il leur dira: pas des valeurs de Grisage ou non, de looking, etc ... d'un bouton ou autre, mais des valeurs représentant le modele indépendemment de toute notion de Vue: un nombre, une chaîne de caractères, une liste d'entités, et même un booléen.

Exemple: le modele intègre la logique de calcul d'un intérêt sur emprunt, lui-même conditionné par une autre valeur propre au modele: ça, c'est la logique intrinsèque et propre au modele: le controleur s'en contre-fiche.
Maintenant admettons q'un bouton de la Vue doive être grisé lorsque le résultat du calcul est supérieur à un montant mntMax donné.
Tout d'abord, selon moi : mntMax est à stocker dans le Contrôleur (car il va s'agir d'implémenter une logique, une stratégie d'affichage: Griser un bouton SI ...).
(Ainsi pour cette même Vue, si on change le Contrôleur, alors on change la STRATEGIE et on peut par exemple avoir un mntMax différent, par exemple parce-que 2 de nos (gros) clients souhaitaient que sur ce point l'interface graphique en question offre une logique et des mntMax différents et personnalisés: donc pour la même Vue, juste le Contrôleur différe (1 par client), et bien sûr entre les 2 clients le modele n'a pas bougé d'un iota, et n'a jamais demandé à Griser un quelconque bouton!).
.
Mais alors on peut se poser la question:
Comment fait le Contrôleur pour savoir que le montant calculé
- (et qui n'est connu que de la Vue, puisque c'est elle seule qui est allée le récupérer ( modele.getData() ) auprès du modele) -
est supérieur au montant mntMax qu'il est lui le seul à connaître?
Ben là j'imagine qu'on pourrait:
Faire en sorte que la Vue appelle systématiquement une méthode du Contrôleur chaque fois qu'elle met à jour son champ Montant Calculé.
Le Contrôleur alors informé, va demander à la Vue de lui renvoyer le Montant
affiché dans le champ, par un this.vue.getChampXValue() (avec this: le Contrôleur), et là le Contrôleur comparera la valeur Mnt reçue avec le mntMax qu'il est le seul à connaître, et SI Mnt>MntMax alors le contrôleur invoquera la méthode de Grisage du bon bouton, la Vue s'éxécutera alors et grisera ce dernier.
Pour moi la Vue n'a pas de CERVEAU, de STRATEGIE, elle raisonne pas
(elle résonne elle fait echo de ce qui lui arrive): elle informe juste son CONTROLEUR de ce qui lui arrive, et le CONTROLEUR lui traduit cela soit:
-en modif. à effectuer sur le modele,
-soit en répercussions graphiques (présentation, activation/désactivation de menus,...) sur la Vue. <<< Je ne dis pas que le Contrôleur doit renseigner sur la Vue des valeurs propres à représenter le modele!


Voilà je reste sur cette vision, pour faire une petite analogie, je dirais:
C'est mon point de VUE, ma façon de présenter le MODELE(read-only) que l'on nomme MVC, .



Tu dis:
"Personnellement je vois plus le contrôleur comme un cablage qui indique quelle action doit être réalisée en fonction de l'évènement reçu par la vue."
C'est une vision intéressante je pense, CEPENDANT à mon sens le rôle du CONTROLEUR ne se limite pas qu'à cela (juste à câbler ou non (ON/OFF) un ordre reçu de l'utilisateur vers une méthode du modele), le rôle du Contrôleur à mon sens, est aussi d'effectuer des raisonnements destinés à impacter la présentation graphique de la Vue, comme explicité plus haut.
Mais là je crois qu'on n'arrive pas à se rejoindre.

PEUT-ETRE l'avis d'une tierce personne pourrait donner matière à conclure
ou approfondir sur ce point!




Tu dis:
"Typiquement le contrôleur aurait tout bénéfice à être implémenté dans une machine à état, chaque état représentant une stratégie."
Je trouve ton idée intéressante, mais resterait à déterminer pourquoi le Contrôleur devrait changer d'état, de Stratégie dynamiquement donc, au cours de l'application? (Je ne pense pas que ça puisse être du fait d'un changement de Vue, car d'une Vue à l'autre le Contrôleur n'a pas forcément les mêmes méthodes à implémenter, donc on ne serait plus dans le pattern Etat, (dans lequel tous les états doivent implémenter les même méthodes )).


Enfin, concernant le dernier point que tu évoques:
"Enfin pour le dernier point, je vais faire...."
C'est effecivement cette solution que j'expose dans mon exemple juste ci-dessus (le Controleur est informé par la Vue que le mnt calculé a changé, il l'interroge alors la Vue pour comparer ce mnt avec le mntMax qu'il connaît, etc...). J'en vois pas d'autre. (J'avoue que ça ressemble un peu à une observation ponctuelle de la Vue par le Controleur).


Voilà ce que je trouve à dire, en rapport avec les divers points que tu soulèves ,en ce qui me concerne ça s'éclaircit, donc merci à toi tristan_m pour les visions, les vues que tu proposes du Modele MVC.
J'espère que pour toi et d'autres ça s'éclaircit aussi, et que que l'on ne sème au contraire pas le trouble dans les esprits!

Je reste à l'écoute(observateur) pour tout point de Vue rejoignant ou, divergeant avec tout ça.

Toutes les réflexions seront les bienvenues, le but restant d'éclaircir, d'enrichir et d'essayer de couvrir la diversité des points de vue en matière de MVC.

Un grand MERCI à tristan_m et à tous ceux qui souhaiterait intervenir.

[rp37000]

D'accord hegros,

Merci pour ces précisions.

[hegros]

je voulais mettre un diagramme de classe pour visualiser le machin voilà c'est fait

[rp37000]

Oui d'accord hegros, merci.

Je suppose que tu voulais dire controlleurIHM3 au lieu de controlleurIHM2,
et controlleurIHM4 au lieu de controlleurIHM3 ?

[hegros]

Oui d'accord hegros, merci.

Je suppose que tu voulais dire controlleurIHM3 au lieu de controlleurIHM2,
et controlleurIHM4 au lieu de controlleurIHM3 ?

non du tout En fait c'est un découpage pour organiser la logique applicative cela doit venir à cause des chiffres cette confusion, voilà un diagramme avec des noms plus parlant je l'espère.

la granularité est à ajuster, là je n'ai que quelques classes dans le diagramme, dans la réalité il y en a des centaines voir des milliers. Aussi l'interet c'est de gagner en cohésion dans les classes logicielles et de diminuer le couplage.

l'interet est de faire avec un court exemple en exposant le plus la chose.

on peut aussi en rester à une définition du pattern controleur : il permet de résoudre le problème de à qui transmettre un message venant d'une IHM cependant dans la réalité on utilise des objets DAO qui sont des controleurs...


On peut dans l'absolu ignorer le controleur dao on voit nettement apparaitre 2 controleurs de métiers différents dans une application cela n'est pas rare. Avec 1 seul controleur pour toutes les IHM et objets métiers il perdrait rapidemment sa cohésion et augmenterait considérablement son couplage avec tout ce qui s'en suit qu'on connait par coeur plus de maintenance et moins de réutilisabilité.

Qu'est-ce que vous en dites les amis ?

[rp37000]

Merci hegros,

Impeccable , nickel c'est beaucoup plus clair pour moi là .

Grâce à toi je découvre la notion de DAO, t je trouve ça très très intéressant:
- http://java.sun.com/blueprints/corej...essObject.html
-Petit Diagramme de séquence (le tien en fait ) :
http://www.developpez.net/forums/d63...onne-pratique/

En fait concernant cette problématique d'accés aux données, ça fait longtemps que je cherchais à "inventer" qqch d'aussi souple que ça, mais seul dans mon coin j'y arrivais pas , je n'étais pas satisfait du résultat.
Ben, vive le Pattern DAO, et pour fêter ça j'ai ouvert une nouvelle
discussion sur justement le Contrôleur DAO, et plus précisément le Transfer Object et son couplage:
http://www.developpez.net/forums/d66...t/#post3903706


Bonne année à tous et toutes, et merci encore!!
En particulier à Tristan_m, hegros et Patriarch24.