Discussion :

[Neckara]

Bonjour,

Après avoir fait en sorte que le Kernel puisse charger Module Manager, il faut que je fasse en sorte que Module Manager puisse charger tous les autres modules.

Pour rappel, un module est, ici, un ensemble de fonctions contenues dans un fichier de bibliothèque dynamique (*.so ou *.dll), que je charge dynamiquement au sein du moteur.

Un module a donc :

• un nom
• une version
• une interface (ensemble des prototype des fonctions qui peuvent être utilisés).
• etc.

On peut alors remarquer qu'il y a deux types d'informations contenus dans le module :

• InfoModule, dont la structure est identique à tous les modules (chaque module a un nom, une version, etc.)
  

  Code :

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

  1
  2
  3
  4
  struct InfoModule {
       std::string nom;
       Version version;
  }

• InterfaceModule, dont la structure change en fonction du module (tous les modules n'offrent pas les même fonctionnalités ).
  

  Code :

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

  1
  2
  3
  4
  5
  struct InterfaceModule {
      void fonction1(void);
      void fonction2(void);
      // autres fonctions offerte par le module
  }

Au chargement du module, il faut donc donner toutes ces informations a Module Manager et aux autres modules susceptibles d'utiliser le module ainsi chargé (qu'on nommera modules utilisateurs).
On sait que chaque modules utilisateurs doit connaitre l'interface proposé par le module chargé pour pouvoir l'utiliser. Ce qui parait assez logique, pour utiliser une fonction "drawImage", les modules utilisateurs doivent savoir qu'elle existe et quel est son prototype.
On peut donc inclure dans chaque modules utilisateurs un fichier d'en-tête décrivant l'interface proposée par le module chargé. Ceci forcera aussi de garder une certaine rétrocompatibilité des modules.

Une autre solution serait de décrire chaque fonctions proposées par l'interface en associant à un nom de fonction, des informations sur ladite fonction :

Code :

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

1
2
3
struct InfoInterface {}
 
std::map<std::string, InfoFonction> interface;

Mais cette méthode pose deux problèmes :

• il va falloir remplir cette structure "à la main", on va dupliquer des informations, bref cela prend du temps et peut être source de données obsolètes.
• le passage des paramètres à la fonction va être source de problèmes
  
  • soit il va falloir caster le pointeur de fonction contenu dans InfoFonction
  • soit il va falloir créer un prototype de fonction "générique" prenant toujours les même paramètres, ce qui devient assez lourd et peu pratique.

Donc Module Manager, en chargeant le module, doit récupérer un objet contenant :

• une instance implémentant InterfaceModule
• une instance de InfoModule

Sachant que les modules utilisateurs connaissent le prototype de InterfaceModule.

On a alors deux choix pour transmettre ces deux instances :

• créer une classe ModuleBase contenant les informations InfoModule et dont tous les modules hériterons :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  class ModuleBase {
       std::string nom;
       Version version;
  }
   
  class ModuleA : public ModuleBase {
       void fonctionA(void);
       // etc....
  }

• inclure dans une structure InfoModule un pointeur vers l'instance d'InfoModule :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  typedef void * InterfaceModule;
   
  class InterfaceModuleA {
  }
   
  class InfoModule {
       std::string nom;
       version version;
       InterfaceModule module;
  }

Toujours est-il qu'on ne pourra pas éviter de caster à moment ou à un autre ModuleBase ou InterfaceModule.
Je préfère éviter d'utiliser l'héritage car elle n'apporte pas grand chose ici par rapport à la deuxième solution.

Mais le fait de devoir caster est un peu embêtant : on a aucune garantie que les modules utilisateurs et le module chargé ai la même définition de l'interface module :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class InterfaceModuleA{
       bool foo(void);
}
 
class InterfaceModuleB {
     void test(std::string);
}
 
InterfaceModuleB interface;
InterfaceModuleA interfaceA= (InterfaceModuleA)interface;
interfaceA.foo(); // erreur !

Pour éviter cela, il faut qu'on puisse attribuer à chaque InterfaceModule une clé unique composée :

• d'une clé unique identifiant le module
• d'un numéro de version (pour différencier les différentes versions d'un même module)

Pour le numéro de version, un simple entier qu'on incrémente à chaque version suffit.
Pour l'identifiant du module, c'est un peu plus compliqué. Il faut aussi forcer les utilisateurs à changer son identifiant lorsqu'ils le forkent.
L'identifiant du module pourrait être composé :

• d'un identifiant spécifique à l'auteur du module, pour cela on peut penser :
  
  • soit à une URL de dépôt git/github
  • soit à une adresse mail de l'auteur
  
  
• un entier

L'identifiant spécifique à l'auteur est donc normalement unique et permet en plus de pouvoir le contacter en cas de problèmes de plus il changera à chaque fork du module.
A partir de là, chaque auteur peut être garant de l'unicité de la seconde partie de l'identifiant (timestamp ou autre).

De là, il suffit d'ajouter les InfoModules dans les modules utilisateurs et d'y ajouter quelques fonctions :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class InfoModule {
     const std::string & moduleURL(void) const {
          const static std::string url = "http://github.com/User/module";
          return url;
     }
 
     const std::string & version(void) const {
          const static Version version = 0;
          return version;
     }
 
     bool compatible( const InfoModule & ) {
          return false;
     }
}

Ainsi, on peut vérifier que les InterfaceModule des modules utilisateurs et des modules utilisés sont compatibles.

---

Je fais quelques essais, je teste quelques pistes pour améliorer la communication.
J'ai essayé de proposer une problèmatique à laquelle je suis confronté et d'y réfléchir ici en donnant la solution que j'envisage tout en tentant de la justifier.
Je ne perd pas vraiment de temps car cela m'oblige à bien réfléchir sur le problème rencontré, de ne pas me précipiter et le fait de l'écrire me donne de nouvelles idées.
Je ne trouve pas que cela est inintéressant, mais pas très adapté à ce média je trouve.



Peut-être qu'un blog DVP serait plus adapté à mon style de communication (?), malheureusement, je n'ai pas l'impression qu'il soit pratique pour les lecteurs de suivre ces blogs ?
Je continu de réfléchir un peu

[Max]

Salut.

Personnellement, je suis globalement du même avis que Vetea . Trop détaillé, trop technique, assez scolaire et très représentatif de l'époque actuelle : si je voulais savoir qu'à 11h12 tu as fait un build et à 15 mangé une pomme - en gros connaître ta vie en live H24 -, bah j'irais sur Facebook, pas ici

Et si on multiplie le temps passé chaque jour à rédiger un long texte ici (plus les différents edit) par le nombre de jours passés sur le projet, bah à la fin ça fera beaucoup beaucoup de temps qui n'est pas passé à avancer réellement sur le concret

En tout cas, je te souhaite bon courage et de la réussite pour mener ton projet à bien

Et puis profite aussi de tes vacances aussi pour couper un peu du dév et du boulot, d'ici peu de temps tu n'en auras plus (ou en tout cas beaucoup moins) !

[Neckara]

J'avais commencé à écrire un message que j'ai "caché" pendant que je finissais de l'écrire, il a donc été posté avant le message de Max.

Pour les détails/horaires, je comprend que c'est plus adapté à un WE jeux, ce n'était peut-être pas une bonne idée/intéressant de le faire sur une durée plus longue.
Pour l'aspect "scolaire", j'ai l'impression que vous parlez surtout de l'aspect rigoureux/organisé, les listes (je peux me tromper), je vous donc mal ce qui vous choque. C'est pourtant un moyen d'afficher un maximum d'informations de la manière la plus lisible et le plus accessible possible.

Pour le temps passé, ce n'est pas vraiment une perte de temps car il faut bien que :

• en début de journée, je fasse le point sur ce que je veux faire
• que je note ce que j'ai fait
• et que je tire des leçons sur la journée

Cela prend certes du temps, mais comme l'analyse ou la conception, ce n'est pas une perte de temps.
Faire déplacer un personnage sur une carte, c'est facile, ça me prendrais ~2 heures, mais derrière il faut aussi voir la qualité du code.
S'il est illisible, peu maintenable, peu évolutif, mal pensé, etc. cela ne peut que poser de futurs problèmes (et à tendance à me donner des boutons ) et engendrera des pertes de temps encore plus grandes.

Bien sûr, l'abus d'analyse/conception est aussi un mal mais leur absence et tout aussi mauvais. Il faut donc trouver un juste milieu, ce qui n'est pas forcément très facile. Mais passer 30min le matin + 10 min à tout casser pendant la journée me semble négligeable face à ~8 heures de dev pendant la journée.

Pour faire une analogie, le "concret" est une sorte de "décoration" qui se place par-dessus les fondations du projet, du moteur.
L'utilisateur ne voit que la "décoration" et ne voit pas les "fondations", pourtant, des fondations mal faites peuvent avoir de grandes répercutions :

• des bugs
• l'ajout/modification de "décoration" compliqué, etc.

[illight]

Et si on multiplie le temps passé chaque jour à rédiger un long texte ici (plus les différents edit) par le nombre de jours passés sur le projet, bah à la fin ça fera beaucoup beaucoup de temps qui n'est pas passé à avancer réellement sur le concret

Je suis pas forcément d'accord : parfois, le fait d'écrire permet d'avoir de nouvelles idées, de pouvoir épancher le sujet, dans le sens où ça permet de l'étaler pour avoir une vue global du travail effectué. Finalement, c'est un peu un mini cahier des charges journalier, et je trouve ça pas mal


Pour revenir à tes questions, je n'ai pas répondu, car je ne suis pas la meilleure personne pour dire si c'est bien ou pas, sachant que je comprend rien n'étant absolument pas dans le dév de ces trucs-là. Néanmoins, ça ne m'empêche pas de lire ce que tu fais

[Max]

Je suis pas forcément d'accord : parfois, le fait d'écrire permet d'avoir de nouvelles idées, de pouvoir épancher le sujet, dans le sens où ça permet de l'étaler pour avoir une vue global du travail effectué. Finalement, c'est un peu un mini cahier des charges journalier, et je trouve ça pas mal

Qu'il le fasse pour lui, pourquoi pas, mais tout détailler ici, poster des bouts de code et algorithmes, des diagrammes UML etc. ça peut vite être fait pour rien . Si on compare avec Vetea : il poste une capture par-ci par là, un petit résumé rapide de ce qu'il a fait et ça suffit à intéresser les gens et ouvrir le débat. C'est ça qui fait que les gens ont accroché à son sujet (enfin je pense). Parce que suivre un projet via ses diagrammes UML, blocs de codes et autres changelogs c'est beaucoup moins fun, pour ne pas dire rébarbatif ou ennuyeux

[Neckara]

Parce que suivre un projet via ses diagrammes UML, blocs de codes et autres changelogs c'est beaucoup moins fun, pour ne pas dire rébarbatif ou ennuyeux

On est pourtant sur un site de développeur, ça devrait être la première chose qui devrait vous intéresser.

Plus sérieusement, sur des forums techniques, je pensais que, plus que les réalisations, ce serait tout ce qui est derrière, comment on a fait, pourquoi, vous intéresseraient.

[Max]

Plus sérieusement, sur des forums techniques, je pensais que, plus que les réalisations, ce serait tout ce qui est derrière, comment on a fait, pourquoi, vous intéresseraient.

C'est un exemple d'un aspect trop scolaire . Dans les grandes lignes, oui, c'est intéressant de savoir que tu as fait tel ou tel choix. Après, ce n'est pas comme si j'étais ton maître de stage qui doit lire ton rapport : bref ce n'est pas suffisamment synthétique . Et puis des détails j'en vois assez dans la journée, pour reprendre l'exemple de Vetea (désolé mais on le connait tous les deux donc c'est le mieux pour qu'on se comprenne ), voir une capture d'un nouveau sprite en pixel art quand je rentre du taff j'adore, analyser un diagramme UML je passe direct mon chemin .

[Neckara]

Bon, ModuleManager peut maintenant :

• charger d'autres modules
• récupérer les informations des autres modules
• récupérer la liste des modules contenus dans un fichier
• décharger tous les modules à sa destruction.

La prochaine étape est donc de documenter le code doxygènement (©Neckara) puis d'écrire le premier "vrai" module : Preferences qui donnera tous les modules à charger en premier pour lancer les demandes de màj, puis les modules à charger après la màj.

[Hinthacy]

Je pense que l’initiative peut être intéressante, si ça permet de faire des échanges d’expériences. Éventuellement, si tu ne veux pas perdre les nouveaux arrivants, tu peux faire un récapitulatif dans le premier post pour donner une vue d’ensemble de ton projet.

Concernant la rédaction, je trouve que tu te concentres trop sur les détails, par-contre je suis totalement pour les diagrammes. J’ai souvent du mal à voir le pourquoi du comment. Par exemple : les « modules », quel est l’objectif ? Pourquoi doivent-ils être chargés dynamiquement ?

Le moteur respecte la structure MVC (Modèle = données, Vue = interactions homme-machine, Contrôleur = règles).

Cette phrase m’a choqué. Peut-être est-ce seulement le choix des mots ? Je ne trouve pas adapté de parler de règles pour le contrôleur. Pour moi, un contrôleur traite les événements mais ne fais aucune analyse. Toute la logique, intelligence, règles du jeu… est le rôle du modèle. De même, le modèle ne se pas réduit pas seulement aux données.

[Neckara]

Par exemple : les « modules », quel est l’objectif ? Pourquoi doivent-ils être chargés dynamiquement ?

Les modules ont un triple objectif :

• faciliter les mises à jour et permettre leur remplacement/substitution très facilement, (on change juste le module sans tout recompiler) ;
• il nous force à définir une interface et ainsi d'avoir un couplage minimal entre les modules ;

Et on les charge dynamiquement pour :

• éviter de devoir recompiler quand on veut ajouter de nouvelle "sorte" de module ;
• ainsi on réduit le couplage entre le "Kernel" et ses différents modules,
• le ModuleManager peut alors charger des modules qu'il ne connait même pas !

Je ne trouve pas adapté de parler de règles pour le contrôleur. Pour moi, un contrôleur traite les événements mais ne fais aucune analyse. Toute la logique, intelligence, règles du jeu… est le rôle du modèle. De même, le modèle ne se pas réduit pas seulement aux données.

Je ne suis pas d'accord avec toi sur ce point.

La définition de Wikipédia me semble fausse et dénue de sens.
Le DP MVC a pour but de séparer Modèle, Vue et Contrôleur afin de pouvoir changer l'un sans changer les autres.

Le modèle ça va surtout être la représentation des données et leur stockage.

La vue, va être tout ce qui est IHM ainsi qu'un premier traitement des événements. En effet, les événements clavier/souris, dépendent de la vue, c'est à la vue d'associer ces événements "primaires", à des évènements plus "explicite".
Ex :

• Événement clic souris => Événement clic bouton1 => Événement "valider".
• Événement clavier => Événement appuie touche 'Y' => Événement "valider".

Dans le cas des événements claviers, c'est un peu particulier car si on propose à l'utilisateur de "mapper" lui-même ses touches pour choisir l'action à enclencher, ce sera au contrôleur de faire le lien entre la touche et l'événement de plus "explicite".
Mais dans le cas d'un GUI par exemple, c'est la vue qui doit définir que le premier bouton ce sera "ok" et le second "valider" ou que le premier ce sera "annuler" et le second "quitter" ou que sais-je encore.

A partir de là, si on met l'algorithme dans le modèle, le MVC n'a plus aucun intérêt :

• l'algorithme est dépendant de la représentation/stockage des données (pas bien ça !) ;
• le contrôleur n'a plus aucun rôle, il va se contenter de récupérer des événements "explicites" via la vue et va directement les transmettre au modèle

[Neckara]

Je ne peux pas éditer (allez savoir pourquoi, je ne peux pas aller sur la deuxième page de ce sujet ), je poste donc à la suite.

J'ai l'impression qu'on trouve pas mal de bêtises (à mon avis) sur le MVC aussi bien sur Wikipedia que sur DVP.
Je pense que le problème vient de framework qui revendiquent faire des structures MVC qui ne sont pas réellement des structures MVC (enfin pas tout à fait).

Certaines descriptions me semblent trop incomplètes, trop ambigüe.
Par exemple, dire que le contrôleur sert d'interface entre l'utilisateur et le modèle est pour moi une aberration.
L'utilisateur ne doit "communiquer" qu'avec la vue, sinon on rend le contrôleur dépendant de la vue ce qui va à l'encontre même du but du DP MVC.

Après je peux me tromper (je ne suis pas infaillible), mais il y a des descriptions du modèle MVC qui n'ont vraiment aucun sens .

Bizarrement les schémas me semble souvent assez juste, plus juste que les descriptions .

[Neckara]

ModuleManager peut maintenant charger correctement des modules dont "PermanantData".

PermanantData remplace Preferences.
Il stockera dans une base de donnée sqlite (domaine public \o/) toutes les données qui devront être sauvegardée d'un lancement de l'application à l'autre.

J'ai passé quelques heures sur un bug de la bibliothèque standard du C++ :
Ils n'ont pas prévu qu'on puisse copier un std::function en provenance d'une dll A dans un std::function d'une autre dll B.
Ainsi, lorsqu'on décharge la dll A, le std::function de la dll A est détruit et le std::function de la dll B se trouve dans un état invalide.
Ainsi lorsqu'on décharge la dll B, on détruit le std::function qui, étant dans un état invalide, fait planter l'application .

Enfin bref, demain, je termine vite fait PermanantData, je fait un UpdateManager bidon et je pourrais commencer ce qui est vraiment marrant :
GameManager qui permettra à l'utilisateur de choisir le jeu qu'il souhaite lancer.

[germinolegrand]

J'ai l'impression qu'on trouve pas mal de bêtises (à mon avis) sur le MVC aussi bien sur Wikipedia que sur DVP.

Peut-être est-ce le MVC lui-même la bêtise ?

J'ai passé quelques heures sur un bug de la bibliothèque standard du C++ :
Ils n'ont pas prévu qu'on puisse copier un std::function en provenance d'une dll A dans un std::function d'une autre dll B.
Ainsi, lorsqu'on décharge la dll A, le std::function de la dll A est détruit et le std::function de la dll B se trouve dans un état invalide.
Ainsi lorsqu'on décharge la dll B, on détruit le std::function qui, étant dans un état invalide, fait planter l'application .

Et ceci n'est pas un bug du tout, c'est normal que si tu décharges la dll tu décharges les classes (et surtout les méthodes) qu'elle contient, les lambdas étant des classes comme les autres elles sont déchargées aussi.

[Neckara]

Et ceci n'est pas un bug du tout, c'est normal que si tu décharges la dll tu décharges les classes (et surtout les méthodes) qu'elle contient, les lambdas étant des classes comme les autres elles sont déchargées aussi.

A quand les std::weak_function ?

[germinolegrand]

A quand les std::weak_function ?

Le jour ou les dll et les processus seront standardisés. Pas avant et à mon avis difficilement après .

[Neckara]

Vivement qu'ils le fassent, depuis le temps que ça aurait du être fait .

Ce qu'il manque vraiment, c'est une allocation sur l'espace mémoire de l'exécutable à partir d'une dll.
Là, on pourrait résoudre le bug auquel j'ai été confronté.

[Hinthacy]

J’ai l’impression que je détourne un peu ton sujet. Cela ne te dérange pas ?

J'ai l'impression qu'on trouve pas mal de bêtises (à mon avis) sur le MVC aussi bien sur Wikipedia que sur DVP.

Si tu cherches une bonne lecture, le livre « Design Patterns-Elements of Reusable Object-Oriented Software » est une référence pour ce qui concerne les patrons de conception.Le MVC est abordé dans l’introduction. Tu peux le trouver sur internet ou dans une BU.

Le DP MVC a pour but de séparer Modèle, Vue et Contrôleur afin de pouvoir changer l'un sans changer les autres.

Le MVC sert surtout à avoir un modèle indépendant afin de pouvoir l’utiliser avec différentes vues. Une vue peut évoluer sans toucher au modèle, mais l’inverse n’est pas toujours possible. En effet, la vue utilise les accesseurs du modèle, donc s’ils changent...

Le modèle ça va surtout être la représentation des données et leur stockage.

Le stockage n’a aucun rapport avec le MVC. Je pense que faire un modèle qui est dépendant de sa persistance n’est pas une bonne idée.

Certaines descriptions me semblent trop incomplètes, trop ambigüe.
Par exemple, dire que le contrôleur sert d'interface entre l'utilisateur et le modèle est pour moi une aberration.
L'utilisateur ne doit "communiquer" qu'avec la vue, sinon on rend le contrôleur dépendant de la vue ce qui va à l'encontre même du but du DP MVC.

La vue, va être tout ce qui est IHM ainsi qu'un premier traitement des événements. En effet, les événements clavier/souris, dépendent de la vue, c'est à la vue d'associer ces événements "primaires", à des évènements plus "explicite".

Si une bibliothèque graphique est construite en respectant le MVC, un composant graphique est un MVC (qui peut être caché derrière une façade). Pour un bouton, le contrôleur filtre les évènements de la souris, modifie l’état du modèle, le modèle génère un événement « bouton relâché »… Les évènements sont enrichis en traversant les couples contrôleur/modèle successivement. Les façades peuvent donner l’impression que les composants graphiques sont seulement des vues, mais ce n’est pas le cas.

A partir de là, si on met l'algorithme dans le modèle, le MVC n'a plus aucun intérêt :

• l'algorithme est dépendant de la représentation/stockage des données (pas bien ça !) ;
• le contrôleur n'a plus aucun rôle, il va se contenter de récupérer des événements "explicites" via la vue et va directement les transmettre au modèle

Si le contrôleur fait une analyse des données pour les modifier, c’est une entorse à l’encapsulation. Je vais prendre l’exemple d’un jeu d’échec pour être plus clair.
Le joueur fait un coup qui lui fait gagner la partie (pour simplifier, on suppose que le joueur ne triche pas) :

• Le joueur choisit un coup
• Le composant « plateau » génère un évènement de déplacement
• Le contrôleur observe l’évènement et demande au modèle d’appliquer le coup
• Le modèle applique le coup
• Le modèle analyse l’état de la partie et détermine un échec et mat
• Le modèle génère un événement d’échec et mat
• Le contrôleur observe cet événement et demande à la vue d’afficher l’échec et mat
• La vue affiche un message d’échec et mat

Ferais-tu différemment ? Qui a le rôle de décider de la fin de la partie selon toi ?

[Neckara]

Le MVC sert surtout à avoir un modèle indépendant afin de pouvoir l’utiliser avec différentes vues. Une vue peut évoluer sans toucher au modèle, mais l’inverse n’est pas toujours possible. En effet, la vue utilise les accesseurs du modèle, donc s’ils changent...

Ce n'est pas parce qu'on change le modèle qu'on est obligé de changer l'interface
D'où l'intérêt des interfaces.

Le stockage n’a aucun rapport avec le MVC. Je pense que faire un modèle qui est dépendant de sa persistance n’est pas une bonne idée.

Si tu accèdes à tes données via ta mémoire vive, via une BDD, etc. ce n'est pas la même chose et c'est au modèle de décider de cela.
Si tu veux accéder à une donnée non plus via la mémoire vive, mais via BDD, tu change ton modèle mais tu ne changes ni la vue, ni le contrôleur.

Si une bibliothèque graphique est construite en respectant le MVC, un composant graphique est un MVC

Attention, on ne parle pas d'une bibliothèque graphique construite en respectant le MVC mais une application complète respectant le MVC, ce n'est pas tout à fait la même chose.
Le contrôleur et le modèle ne doivent en aucun cas avoir des interactions avec cette bibliothèque graphique sinon tu les rends dépendant de la vue .

Si le contrôleur fait une analyse des données pour les modifier, c’est une entorse à l’encapsulation.

Qui te parle d'analyser les données ?

• Le joueur choisit un coup
• Le composant « plateau » génère un évènement de déplacement
• Le contrôleur observe l’évènement et demande au modèle d’appliquer le coup
• Le modèle applique le coup
• Le modèle analyse l’état de la partie et détermine un échec et mat
• Le modèle génère un événement d’échec et mat
• Le contrôleur observe cet événement et demande à la vue d’afficher l’échec et mat
• La vue affiche un message d’échec et mat

Ferais-tu différemment ? Qui a le rôle de décider de la fin de la partie selon toi ?

A quoi sert le contrôleur ici ? Il se contente de relayer des messages, autant laisser la vue et le modèle dialoguer directement entre eux.

• Vue (Console) : Reçoit A10 -> A20 sur l'entrée standard
• Vue (Console) : envoie un événement move(A10, A20) au contrôleur.
• Contrôleur : demande à modèle ce qu'il y a à la case A10 et à la case A20
• Contrôleur : valide l'action et informe le modèle du déplacement
• Modèle : met à jour les données
• Modèle : notifie la vue d'un changement

Le MVP & MVVM : Modèle-Vue-Presentation et Modèle-Vue-VueModèle a une seule différence il me semble :

• Modèle : notifie la vue d'un changement
• Controleur : ordonne à la vue d'effectuer le changement

Je ne rentre pas dans les détails quant à la différence MVP & MVVM.


Ainsi :

• On remplace une vue console par une vue Gui, on déplace/rajoute un bouton ou on change le rendu d'une pièce : contrôleur + modèle inchangés ;
• On remplace le modèle par en modèle permettant des parties en lignes : Vue + contrôleur inchangés ;
• On remplace une règle dans le contrôleur (la reine peut se téléporter) : Vue + modèle inchangés.

Pour moi, c'est ça l'intérêt du MVC, après je ne peux pas lire ton livre, mais c'est ainsi que je l'ai appris.
D'ailleurs la version anglaises des pages Wikipédia de MVC, MVVM et MVP semblent me donner raison.

[Hinthacy]

• Vue (Console) : Reçoit A10 -> A20 sur l'entrée standard
• Vue (Console) : envoie un événement move(A10, A20) au contrôleur.
• Contrôleur : demande à modèle ce qu'il y a à la case A10 et à la case A20
• Contrôleur : valide l'action et informe le modèle du déplacement
• Modèle : met à jour les données
• Modèle : notifie la vue d'un changement

Je trouve ton exemple bien choisi. Je crois avoir cerné ce sur quoi nos avis divergent. Pour moi c’est au modèle de déterminer si l’action est valide et non pas au contrôleur.
Voici comment je l’aurais fait :

• Le contrôleur de la console traduit les actions du clavier en chaine : « A10 -> A20 » et demande à son modèle de traiter la commande
• Le modèle de la console sait qu’un programme est en cours et lui transmet la chaine

(L'exécution passe dans le programme)

• Le contrôleur du jeu reçoit la commande et la décode
• Le contrôleur du jeu demande au modèle du jeu d’effectuer le déplacement
• Le modèle du jeu vérifie la validité du mouvement selon les règles du jeu, applique le mouvement et retourne vrai
• Le contrôleur demande à la vue de se mettre à jour
• La vue du jeu se met à jour en envoyant une représentation textuelle à afficher à la console

(L'exécution sort du programme)

• La vue de la console affiche ce texte à l’écran

L’avantage d’avoir les règles du jeu dans le modèle est d’assurer la cohérence des données. Si le modèle est valide aucun test unitaire ne pourra aboutir à une partie de jeu incohérente.

J’ai cherché quelques sources pour appuyer mes arguments. Je suis tombé sur celles-ci :

Microsoft

The model manages the behavior and data of the application domain.

Sun

The model represents data and the rules that govern access to and updates of this data.

Peut-être que je n’interprète pas correctement en disant que les règles du jeu (behavior, rules that govern updates) sont le rôle du modèle.
Qu’en penses-tu ? Aurais-tu des sources qui contrediraient cela ?

[Neckara]

Ce que je ne comprend pas dans tes exemples, c'est l'intérêt du contrôleur, à quoi sert-il ?
Il est entièrement dépendant de la vue, au final tu fait un Modèle-VueControleur.

L’avantage d’avoir les règles du jeu dans le modèle est d’assurer la cohérence des données. Si le modèle est valide aucun test unitaire ne pourra aboutir à une partie de jeu incohérente.

Tu confonds deux choses :

• la cohérence des données
• les règles du jeux

Le modèle représente et encapsule les données du jeu, ils seront toujours dans un état cohérent.
Le contrôleur, quant à lui, va demander au modèle de modifier des données après avoir vérifier que l'action est "autorisé".

Un modèle peut être réutilisé dans plusieurs jeux.
Et dans ce cas là, on changera le contrôleur pour faire :

• un jeu de dames
• un jeu d'échec

Tout en laissant la vue intacte.

Je ne voudrais pas troller, mais Microsoft est une source très peu crédible à mes yeux.

represents data and the rules that govern access to and updates of this data.

Donc le modèle :

• représente les données
  
  • ~ données encapsulée
  
  
• les règles d'accès aux données => le format de stockage des données + d'éventuels droits d'accès, c'est ce que je disais.
  
  • ~ "getter"
  
  
• les règles de mises à jour des donnés => le modèle met lui-même à jour les données = encapsulation, rien de plus pour moi.
  
  • ~ "setter"

Sun ne dit pas que c'est au modèle de décider si une action est valide ou non.

Bon wikipédia n'est pas une source très fiable mais j'ai :

controller : can send commands to the model to update the model's state

=> il envoi des commandes pour mettre à jour l'état du modèle, on dit bien "pour mettre à jour l'état du modèle", pour moi cela sous-entends que le contrôleur a bien "validé" le mouvement selon les règles du jeu.

A model notifies its associated views and controllers when there has been a change in its state.

On ne parle pas de vérification des "règles" mais de notification d'un changement d'état.

Après, je peux me tromper, mais dans la structure MVC que tu présente, le contrôleur n'a pour moi aucun intérêt et fait, en raison de son fort couplage avec la vue, presque parti de la vue.