Salut tout le monde, comme projet pour la fac j'ai a réaliser un jeu de dame en java qui se joue seulement entre utilisateurs... J'ai déja quelques class : plateau, case, player, pion, dame... J'ai déja tester mes class pour les deplacement et les prises et on m a di que je devais réaliser une class controler pour faire un lien entre mon code et l'interface graphique. Je n'ai encore jamais fai d'interface graphique et je ne comprend pas trop comment cette class controleur fonctionne...est ce que quelqu un serait m expliquer ?

Hello,

je ne sais pas si as entendu parlé de MVC. (Modèle Vue Contrôleur)
C'est un schéma de conception dont l'idée principale et de séparer ton code en 3 parties distinctes qui sont le modèle, la vue et le contrôleur.

En Java, tu as les class Observer et Observable qui peuvent t'aider.

L'idée c'est d'un côté avoir l'interface graphique IHM qui est un Observer et qui va se contenter d'afficher les infos du Modèle (Observable)
Le contrôleur c'est simplement la class qui va gérer les interactions entre le modèle et la vue.

par exemple le contrôleur va recevoir une touche saisie au clavier. Il va en informer le modèle qui va mettre à jour ses données. Le modèle va mettre à jour la vue qui va afficher ce qu'il faut.

voilà un exemple simple à mettre en oeuvre :

http://fr.wikipedia.org/wiki/Observateur_(patron_de_conception)#Un_exemple_en_langage_Java

Personnellement , je ne trouve pas du tout qu'un projet de jeux en Java correspond a un MVC mais après ce n'est que moi , le model interagissant normalement avec une base de donnée converti en methodes de classes... Or ce ne peut être le cas sauf pour eventuellement un MMORPG.

Pour le controlleur je suis d'accord à 100 % avec ce qui a été dit au dessus , c'est dans ton controlleur que tu défini toutes les interactions et ensuite tu appelera ce controlleur dans ta classe graphique.

C'est classique comme projet pour un DUT.
Nous on avait appris le MVC en faisant un morpion/tic tac toe.

L'idée c'est surtout d'apprendre un maîtriser un concept nouveau et de s'essayer à un "premier modèle de conception".

Donc on code uniquement les 3 parties, on n'utilise pas de base de données ni de couche d'abstraction pour la base de données et on ne pense pas non plus aux applications n tiers avec des couches bien distinctes qui se superposent.

(sauf si c'est la consigne du prof ;) )

Je crois qu'en DUT, mis à part le Singleton et le MVC,nous n'avions pas étudié d'autres design patterns.

Par contre en licence on en avait bouffé ;)

mvc se prete bien a se genre de jeux.
tout comme swing ou Qt

dame echec et tout autre jeux de la sorte

ta vue va etre normalement plein de bouton, ou au 1er click seul les case(bouton) avec un pion seron sélectionnable.

donc ton utilisateur clique sur un bonton(pion) la ton controleur identifie sur quel bouton il a clicker puis en informe le model. le Model agis en conséqence par exemple dit tel bouton a été sélectionné et demande a la vue de par exemple colorier le fond de ce bouton en bleu.

Je n'ai jamais aime le model MVC. Dans la plupart des applications, je trouve qu'il n'a pas de sens.
La plupart du temps, le controller et la vue sont physiquement la meme chose. Ici une fenetre qui affiche l'etat du jeu et sur lequel tu clique.
Du coup essayer de les separer en deux chose differente est tres tres arbitraire.
La separation avec le controlleur est tres arbitraire egalement. Pour reprendre la probleme des dames. informer le model du jeu (le moteur) que l'utilisateur va peut etre bouger tel pion ca n'a absolument aucun sens. C'est purement un probleme d'interfacage qui a mon sens n'a pas a etre dans le modele...

Enfin, les gouts, les couleurs...

tout ce qui est etat est dans le model.
le controleur ne fait que appeler les méthodes du model suivant le bouton sélectionner et/ou le model lui meme.
les méthode du model qui ont une influence sur la vue tu leur fou ton notify et je sais plus quoi et dans ton update(vue) tu indiques les modifications de celle ci .

ca évite les popote personnelle et ca fait un code qui suit une structure connu par normalement la plupart des codeurs.

mainteant ca n'est pas adapter a tout les programmes.
mais Swing (ou Qt) + mvc pour les jeux de plateau c'est juste terrible.

Le fait de splitter ton controler et ta vue, te permettra de lancer 2 vue sur 1 modèle.
Implicitement, ta vue affiche, tes controleurs transmettent les infos et ton model les traites.
Celà évite aussi à avoir plusieurs données et t'emmellées les pinceaux.
Si je peux te donner un conseil, split un maximum, t'es mieux d'avoir plusieurs classes distingues que moins et regrouper trop d'infos.
Dans ton cas, imaginons 2 users avec 2 écrans, tu peux faire un camp bleu, un rouge, chaqu'un son screen perso sans rien avoir à toucher d'autre que ta vue!
Courage à toi, moi j'ai terminé en juin ;)