> Il doivent implémenter l'interface joueur qui demande
> la méthode jouer().
D'accord. Mais c'est là le problème. Qui va appeler la méthode jouer de l'ordinateur ?
Si on se place avec une interface ligne de commande c'est simple, on a un objet C qui appele successivement les méthodes jouer() des deux joueurs, qu'ils soient humains ou pas.
Maintenant avec une interface graphique, on ne peut pas faire ça puisque c'est l'interface (par le contrôleur) qui va appeler les méthodes jouer().
>Pour le joueur IA, jouer() veut dire: calculer le coup, le jouer et
> mettre à jour la vue.
Dans le MVC, ce n'est pas tout à fait ça... jouer() met à jour le modèle, et le modèle appele la méthode update() de toutes les vues qui sont enregistrées.
C'est pour cela que j'ai créé un objet à la fois vue et contrôleur : comme la vue est la seule à être prévenue d'un changement de modèle, et que le contrôleur est le seul à pouvoir mettre à jour le modèle, ça paraît cohérent.
>Ta méthode de faire en sorte qu'une vue soit aussi un
> contrôleur me surpasse totalement.... Le modèle MVC sépare
> justement ces deux entités pour que l'on ne s'embrouille pas
> les pinceaux.
Le but est surtout de séparer le modèle de l'interface (vue+contrôleur). D'après ce que j'ai pu voir, vue et contrôleur sont souvent liés.
[^] # Re: Re :
Posté par norbs . En réponse au journal Problème de conception pour un jeu. Évalué à 1.
> la méthode jouer().
D'accord. Mais c'est là le problème. Qui va appeler la méthode jouer de l'ordinateur ?
Si on se place avec une interface ligne de commande c'est simple, on a un objet C qui appele successivement les méthodes jouer() des deux joueurs, qu'ils soient humains ou pas.
Maintenant avec une interface graphique, on ne peut pas faire ça puisque c'est l'interface (par le contrôleur) qui va appeler les méthodes jouer().
>Pour le joueur IA, jouer() veut dire: calculer le coup, le jouer et
> mettre à jour la vue.
Dans le MVC, ce n'est pas tout à fait ça... jouer() met à jour le modèle, et le modèle appele la méthode update() de toutes les vues qui sont enregistrées.
C'est pour cela que j'ai créé un objet à la fois vue et contrôleur : comme la vue est la seule à être prévenue d'un changement de modèle, et que le contrôleur est le seul à pouvoir mettre à jour le modèle, ça paraît cohérent.
>Ta méthode de faire en sorte qu'une vue soit aussi un
> contrôleur me surpasse totalement.... Le modèle MVC sépare
> justement ces deux entités pour que l'on ne s'embrouille pas
> les pinceaux.
Le but est surtout de séparer le modèle de l'interface (vue+contrôleur). D'après ce que j'ai pu voir, vue et contrôleur sont souvent liés.