Bonjour
 
Je dois programmer un Puissance4, et j'aimerais que quelqu'un me donne son avis sur la conception objet que j'ai choisie :  
 
J'ai une classe Interface, qui extends un JPanel et qui lui ajoute les composants graphiques nécessaires (cases pour mettre les jetons).
 
Ensuite, une classe Partie qui s'occupe de la gestion "logique" de la partie.
 
Enfin, une classe principale Puissance4 qui extends JFrame, qui a pour attributs une instance des 2 classes précédentes, et qui contient le main().
 
Est-ce que cette conception objet vous paraît correcte ?
 
Merci
 
 
PS : Le problème c'est que je ne sais pas comment "transmettre" les évènements comme le clic d'un joueur sur une case à la classe Puissance4 (puisque c'est la classe Interface qui le récupère).
 
 
 

c'est pas tres poussé mais c'est un bon debut.
à priori , tu vas devoir passer une reference de Partie à Interface (à propos, trouve un autre nom qu'Interface pour une classe concrete), et c'est à cette reference que tu transmettras les evenements... attention, "Partie", ne devrait pas avoir a faire a des "clicks", mais par exemple à un deplacement de pion.

up

ben quoi ? ca et va pas ce qu'a dit moins moins ?

Si si mais j'aimerais avoir plusieurs avis

même avis que moinsmoins.

D'accord d'accord, merci
 
(On m'a toujours dit qu'il n'y a pas qu'une seule façon de "modéliser" un pb en prog objet, c'est pour ça que voulais plusieurs avis)

oui enfin y'a qd meme des bases communes.
cela dit le fait de passer une ref de Partie à ta GUI est une solution simple qui ne serait pas la meilleure pour une appli plus complexe.
 

en fait je cherche une idée plus clean, parce que justement ça m'emmerde toujours de passer des references d'objets métier à des classes de gui, mais je vois pas là

Il faut un médiateur, qui connaissent les 2, et qui fasse la jonction. En design pattenrs, on appelle ça un "Contrôleur", qui fait l'interface entre le "Modèle" et la "Vue" (du fameux modèle MVC, donc).

yes!
 
mais donc faut passer une ref du mediateur a la vue...

Non, c'est le contrôleur qui a entièrement la main. C'est lui qui invoque les méthodes du modèle pour qu'il change, et c'est encore lui qui demande aux vues de se rafraîchir.
 
edit> Le contrôleur doit également "écouter" les modifications de modèle venant d'une des vues (c'est la raison d'être des "Listeners" en Java). Il peut alors être au courant des modifications de données, demander au modèle de changer tel partie de son état, et demander aux autres vues de se rafraîchir.

ui voila, donc le controller A ou EST un listener de la vue.
(ce qui ne change concretement pas gd chose au fait que la vue ait une reference vers le controlleur, a part que c'est un peu plus abstrait )

ça me donne envie de faire un puissance4

Fais-le en SWT, alors

 
Qu'est-ce que c'est ?

Une API d'interface graphique qui a bien plus de couilles que Swing ou AWT (cette dernière remarque était destinée à faire chier benou ). http://www.eclipse.org/swt

en emme temps t'as quand meme un idea qu'est en swing et 10x plus rapide qu'un eclipse

mais je m'en fous moi

Franchement, sur 2 applis équivalentes l'une en swing et l'ôt en SWT, y a pas photo, j'trouve SWT bien plus réactif (normal, en même temps)

Une question à propos du puissance4 :
 
Quand la classe Vue (que j'appelais Interface au début... humhum...) détecte un clic, comment je le transmets à la classe principale Puissance4 ?

ben moi je dirais que la classe Puissance4 elle s'en fout qu'il y a eu un clic. Elle ce qui l'intéresserait plutot ce serait "le joueur courant a jouer dans la colone 3" par exemple.
 
C'est l'utilité du Controleur : il fait le pont entre l'interface graphique et la logique applicative.

 
Alors c'est le contrôleur qui donne successivement la main aux joueurs, qui récupère la colonne dans laquelle ils jouent, et qui transmet ce numéro de colonne à l'objet Vue ?
 
Ca me paraît pas mal ça

Partie

 
Quelqu'un a dû éditer mon post  
 
Merci merci
 

je me demande bien comment ils ont fait pour IDEA qd meme

clair, c'est hallucinant
ils devraient ouvrir leur api, et taiche arreterait de nous casser les couilles avec son swt de merde

C'est re-moi
 
J'ai (encore) un petit pb : Dans ma classe Vue, je veux redéfinir la méthode PaintComponent() pour pouvoir redessiner les "cases" du plateau de jeu à chaque fois que c'est nécessaire. Le problème c'est que je ne connais pas le contenu de ces cases (vide OU pion jaune OU pion rouge) car cette information est stockée dans la classe Partie, sous forme d'un tableau à double entrées.
 
Ma question est donc : comment faire pour pouvoir mettre à jour l'affichage sans avoir à faire une copie de ce tableau dans la classe Vue (ce qui va à l'encontre du modèle MVC je pense) ?

c'est toujours le même pricipe : la vue doit demander les infos au controleur qui les demandera l'objet Logique ...

 
Bon alors tant pis, j'étale mon incompétence : Comment la vue peut-elle demander les infos au contrôleur, puisque Vue est un attribut du contrôleur, et pas l'inverse ?
 
Sachant que mon contrôleur (qui est ma classe principale, avec le main() et tout le toutim) s'appelle Puissance4, est-ce qu'écrire "Puissance4.maMethode()" dans Vue est "propre" ?
 
Et une autre question : Etant donné que ces infos sont nécessaires à chaque fois que la fenêtre est redessinée, est-ce que le fait de demander ces infos au contrôleur, qui lui même les demande à l'objet Logique ne revient pas à brasser beaucoup d'air pour pas grand-chose ?

ben je vois rien de particulièrement choquant à ce la vue "connaisse" le controlleur et puisse dialoguer avec.
 

dans ce cas oui : c'est juste un pont. c'est le prix à payer pour un modèle MVC propre .
 
Y a d'autres cas où ca a vraiment un sens : pour la gestion des évenements par exemple.  
 

Ouais pis au lieu de vendre leur merde de soft 700 euros, ils foutraient tout open source Et pis on devrait tous se mettre tout nus pour courir dans les champs et aller taper la discute avec les Bisounours

 
La vue définit les événements qu'elle émet, et permet à des listeners de recevoir ces événements => tu définis une classe EvenementPuissance4 et une interface ListenerPuissance4 avec le prototype de la ou des des méthodes qu'une classe recevant des EvenementPuissance4 doit implémenter. La classe Vue contient un tableau de ListenerPuissance4, et possède au moins 3 méthodes "void addListener(ListenerPuissance4 listener)" (pour ajouter un nouveau listener), "void removeListener(ListenerPuissance4 listener)" (pour enlever un listener de la liste des listeners), et "void fireEvent(EvenementPuissance4 event)" (pour envoyer un événement à tous les listeners). Et évidemment, ton Controleur implémente ListenerPuissance4 et s'enregistre auprès de la ou des vues en tant que listener des événements qu'elle(s) émet(tent).
 
Ainsi, ta vue n'aura aucune connaissance particulière du contrôleur, et s'adressera uniquement à des listeners abstraits. La communication entre vues et contrôleur sera formalisée et parfaitement spécifiée par l'interface ListenerPuissance4.