Discussion :

[alalalola]

Bonjour,

je débute en C++, et en MVC aussi tant qu'à faire :-)
je cherche à lier mes trois objets et déjà je n'ai pas trouvé sur internet une seule et bonne méthode (quelques soient les langages). Je suis donc partie de l'idée qu'on appelait le contrôleur, et qu'à l'intérieur de celui-ci on instanciait le modèle et la vue, en passant this en argument.
Est-ce que déjà dans l'idée ça vous semble correcte ? (la meilleure solution, s'il y en a une)

J'ai donc essayé cela, et ça marchait plutôt pas mal :

Code :

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

1
2
3
4
5
6
7
#include "Media_model.h"
#include "Media_view.h"
 
Media_controller::Media_controller(void){
    Media_model *model = new Media_model;
    Media_view *view = new Media_view(this);
}

Sauf que j'aimerai maintenant que ma variable view devienne un attribut de ma classe, du style :

Code :

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

1
2
3
4
Media_controller::Media_controller(void){
    model = new Media_model;
    view = new Media_view(this);
}

et dans le .h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include "Media_model.h"
#include "Media_view.h"
 
class Media_controller{
    public :
        Media_controller(void);
 
    private :
        Media_model *model;
        Media_view *view;
};

et là ça ne marche plus du tout... Pour le modèle il n'y a aucun problème, ça fonctionne très bien. J'ai donc fais des tas de tests différents sur la vue, j'ai remarqué que si je passais un Int à la place de this, ça fonctionne sans problème.

Voici le code de ma vue :

Code :

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

1
2
3
4
5
6
7
#include <iostream>
#include "Media_controller.h"
 
class Media_view{
    public :
        Media_view(Media_controller *controller_);
};

et le .cpp :

Code :

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

1
2
3
4
5
6
7
#include "Media_view.h"
 
using namespace std;
 
Media_view::Media_view(Media_controller *controller_){
    cout << "Media_view" << endl;
}

Autre question aussi, j'ai lu que pour passer un objet, il fallait écrire *this, mais dans ce cas, ma vue n'accepte plus

Code :

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

Media_controller *controller_

mais

Code :

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

Media_controller controller_

en argument. Ce qui fait que pour accéder à une méthode du contrôleur, je devrais utiliser

Code :

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

controller_.maMethode()

au lieu de

Code :

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

controler_->maMethode()

Du coup je suis perdue... je pensais que l'étoile et la flèche allaient de paire, que cela signifiait qu'on utilisait une méthode dynamique. Et à l'inverse, sans l'étoile et le point, une méthode statique.

Merci d'avance pour vos lumière, je me perds un peu :-s

[Invité]

Bonjour,

Pour mettre la vue en membre du controller, je crois que tu es face à un problème de référence croisées

Pour ce qui est du this, c'est un pointeur. Si tu le déréférence tu obtiens une référence. Il faut donc que tu passe MediaController à ta vue par référence et non par valeur.

En fait ce que tu as retenu des pointeurs, dynamisme, etc... me parait un peu biaisé... Je te conseille vivement de lire l'article 3DArchi sur les fonctions virtuelles

[alalalola]

Ca fonctionne avec les déclarations anticipées, merci beaucoup

Je vais étudier ton lien en détail, effectivement c'est pas très clair dans ma tête.

Merci encore,
à +

[r0d]

Bonjour,

Personnellement, pour un MVC, je conseille de séparer les 3 modules le plus possible (quitte à dupliquer, parfois, certaines données; mais attention: dupliquer des données de signifie pas dupliquer du code). Ensuite, je pense que le mieux est d'utiliser les 3 modules dans un main à part.

Par exemple, si ton découpage est "théoriquement parfait", tu auras 3 classes: Model, View, Controller. Et ton main ressemblera quelque chose comme ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
main()
{
   Controller controller( /* params */ );
   Model model( /* params */ );
   View view( /* params */ );
   while ( controller.Continue() )
   {
      controller.PollEvents();
      model.Update( controller );
      view.DrawFrame( model );
   }
}

D'expérience, c'est le patron le plus simple (donc le moins compliqué, c'est toujours important de le rappeler) et le plus générique. Mais j'avoue que ce n'est pas le meilleur découpage, et surtout, ça ne fonctionne quand-même pas dans tous les cas.

Ce qui est important dans ce patron c'est:
1. Le controller n'a besoin de rien ni personne. Il doit se débrouiller tout seul.
2. Le model a besoin du controlleur pour mettre ses données à jour et la view a besoin du model pour savoir ce qu'il doit afficher.

En terme de lambda calcul, on dit que le Model et la View on besoin du contexte. J'insiste sur cette notion de contexte qui, issu des mathématiques théorique, est primordial dans la conception de logiciel (et dans la conception globalement, dans l'ingénierie en général).

La notion de contexte est antagoniste du paradigme template (mais pas insoluble). "Penser" en template consiste à penser au niveau atomique, tout en bas; alors que penser en terme de contexte est une vision globale, tout en haut. La puissance du c++ est qu'il permet l'utilisation de ces divers paradigmes en même temps et à bon escient.

[alalalola]

Bonjour r0d,

Merci pour ces précisions, je me retrouve encore avec un nouveau patron de plus :-) Finalement chaque programmeur reproduit le modèle MVC à sa sauce, l'important étant que les 3 classes soient bien découpées. Les relations entre elles dépendent de la nécessité du programme j'imagine, et des habitudes du programmeur, non ?

Il n'existe pas un schéma "officiel" ?

Si j'ai bien compris, avec ton patron, on appelle d'abord la View, qui va chercher les données à afficher dans le Model, qui lui même va demander au Controller de les traiter, c'est bien cela ?
Imaginons que l'utilisateur clique sur un bouton, nous souhaiterions que cette action implique un changement de View. Il ne sert à rien de passer par le Model, il suffirait simplement d'avertir le Controller, mais dans ce schema la View ne dialogue pas directement avec le Controller. Alors comment faire ?
Et si je souhaite mettre à jour des données avant l'affichage de la View ?

...Je pense ne pas avoir tout compris à ton patron...

Si tu as un site sur le MVC du point de vue théorique (sans qu'il soit appliqué à un langage particulier) et qui respecte suffisamment les normes, je suis preneuse :-)

Merci de ton aide,
Lola

[r0d]

Finalement chaque programmeur reproduit le modèle MVC à sa sauce,

Exactement. C'est le principe même d'un patron de conception. Bon, MVC n'est pas vraiment un patron, disons plutôt une méthode de conception, mais cela revient au même.

l'important étant que les 3 classes soient bien découpées.

En fait c'est un petit peu plus compliqué. Pour faire simple, l'important est de bien adapter la méthode à notre problème. Cette remarque ne fait pas beaucoup avancer le shmilblick, j'en conviens, mais pour être plus précis il faudrait beaucoup - trop - de temps (surtout du temps d'investigation et de vérifications pour s'assurer que je ne raconte pas trop de bêtises).

Les relations entre elles dépendent de la nécessité du programme j'imagine, et des habitudes du programmeur, non ?

Oui. Mais aussi du langage de programmation utilisé (chaque langage ayant ses contraintes), du contexte (souvent notre programme n'est qu'une brique d'un ensemble plus grand), etc.

Il n'existe pas un schéma "officiel" ?

Disons qu'il y a un schéma accepté. C'est celui de la page wikipedia, et qui est assez différent de celui que je préconise généralement.

Imaginons que l'utilisateur clique sur un bouton, nous souhaiterions que cette action implique un changement de View. Il ne sert à rien de passer par le Model, il suffirait simplement d'avertir le Controller, mais dans ce schema la View ne dialogue pas directement avec le Controller. Alors comment faire ?

Effectivement, c'est un cas dans lequel mon patron ne cadre pas bien. Le modèle que je propose ci-dessus suppose qu'il n'y a aucun lien direct entre la view et le controller. Cette méthode offre (entres autres choses) un découpage tellement fort qu'elle est spécialement adéquate pour les applications réseau, par la possibilité de création quasiment gratuite du client lorsque le serveur est implémenté.
Dans le cas où un résultat (résultat dans le sens de "output") du controller va affecter la view mais pas les classes métier, il faut effectivement que le controller puisse accéder à la view, et donc le schéma "classique" est plus opportun.

Mais là il y a plusieurs choses à prendre en compte:

- Un clic de souris va générer une action. En gros, le controller reçoit un point (x,y): les coordonnées du clic. Question: qui doit prendre la décision de ce qu'il faut faire selon le contexte? Ici le contexte peut être le plus simple du monde, comme par exemple juste savoir à quel endroit sont les boutons de l'IHM, mais il peut être extrêmement complexe, avec différents objets dont les états vont influencer la prise de décision. Cela dépend de ton programme, c'est pourquoi je ne peux pas y répondre, mais il faut que toi tu puisse y répondre avant de commencer à coder.

- Si tu "ouvres un puit" entre le controller et la view, cela peut être dangereux. Peut-être pas, cela dépend de ton programme. Mais par exemple dans le cas d'une programme qui va fonctionner en réseau, ce "puit" peut poser tout un tas de problèmes (je pense par exemple au moteur de règles). J'insiste sur le fait que cela peut poser des problèmes, mais ce n'est absolument pas certain.

- Prenons par exemple un clic sur un bouton à deux états (up et down) qui se met en position "down" lorsqu'on clique dessus et qui effectue une action lorsqu'on lâche le bouton de la souris. La séquence qui parait logique est la suivante:
1. Le controller reçoit un évenement MouseClic( x, y, left_button )
2. Le controller appelle la fonction membre de la view: View::OnLeftClic( x, y );
3. A l'intérieur de View::OnLeftClic( x, y ), on récupère le bouton auquel le pixel (x,y) appartient
4. On met le bouton en état Down (en général, les boutons ont 3 états: up, down et hover)

Cette séquence est très bien. Seulement que va-t-il se passer lorsque l'utilisateur lâche la souris? Est-ce le controller ou la view qui va appeler le model? Si c'est la view, tu vas te retrouver avec un plat de spaghetti (des liens entre tous les modules). Si c'est le controller, le problème est: comment le controller peut-il savoir quelle fonctionnalité du model faut-il appeler?

La bonne façon de faire dépend spécifiquement, encore une fois, de ton programme.

Et si je souhaite mettre à jour des données avant l'affichage de la View ?

Cette question n'a pas vraiment de sens, ou alors quelque chose m'échappe. En effet, on est dans une boucle: 1. récupération des inputs (clavier, souris, réseau, etc.) 2. on update les données, 3. on affiche ces données, puis on recommence. Il n'y a pas vraiment de "avant" et "après".

Si tu as un site sur le MVC du point de vue théorique (sans qu'il soit appliqué à un langage particulier) et qui respecte suffisamment les normes, je suis preneuse :-)

Non désolé. Sur ce suejt, je n'ai comme connaissance que ma propre expérience. Mais déjà la page wikipedia est pas mal. Et puis tu peux aller demander dans la partie "conception" du forum, là-bas il y a des gens qui sauront sans doute t'aider plus efficacement.

Mais de toutes façons, le MVC est une méthode très ouverte, et je crois que la meilleure façon d'en cerner le pourquoi et le comment est de "mettre les mains dans le camboui"; d'essayer des choses et de voir ce que ça donne concrètement.

[alalalola]

Ok je comprends maintenant l'intérêt de ta "méthode de conception".
Par rapport à l'idée de mettre des données à jour avant de les afficher, je pensais par exemple à si j'ai un champ "date" (dateTime) dans ma table, et un champ "archive" (boolean), que je souhaite vérifier à chaque lancement de programme si une date est passée de plus de 2semaines (par rapport à aujourd'hui), dans ce cas le champ "archive" devrait passer à 1. Bon c'est un cas un peu particulier c'est vrai...

Merci pour toutes ces explications, je ne chercherai plus LE model MVC officiel, mais plutôt à me l'approprier ;-)

à bientôt

Lola