Previous Up Next

Séance 11 (10/01/2017, 18:00)

Annales 2 : NFP 121 Paris 2007 session 1 (suite)

Continuation du thème Annales 2 de la séance Séance 10

TD 9 : Encore les segments et les points !

Le TD 9 propose de réfléchir à une nouvelle manière d’écrire les points et les segments en respectant une contrainte de réalisation : la longueur du segment est stockée dans un attribut.

Ce « cas d’école » permet de présenter une solution intéressante qui, en particulier, est utilisée pour la programmation des interfaces graphiques en Java.

Voici les fichiers mentionnés dans le sujet.

TP 15 : Classes internes et patron observateur

Le TP 15 propose de mettre en pratique le patron de conception « Observateur ».

Attention : Ceci n’est pas dit explicitement dans le sujet mais il faut utiliser la généricité et autres améliorations apportées par Java 1.5 pour écrire la classe GroupeObservateurs.

Voici les fichiers fournis.

Solution : Voici une solution possible pour l’ensemble du TP... et une solution qui s’appuie sur les observateurs de l’API Java.

Voir le TD correspondant pour une solution plus progressive.

CM 9 : Swing, GUI et programmation événementielle

Ce cours concerne la programmation des interfaces graphiques en Java/Swing. Voici la présentation qui sera utilisée.

Annales 2 : NFP 121 Paris 2007 session 1 (suite)

Continuation du thème Annales 2 de la séance Séance 10

TP 16 : Jeu du Morpion

Le TP 16 consiste à construire une première application Java/Swing simple en programmant un jeu de Morpion avec une interface graphique.

Une fois cette application développée, on pourra essayer de mettre en pratique le patron MVC...

Voici les fichiers fournis.

Solution : Si le modèle du jeu de Morpion n’avait pas été donné, on aurait pu avoir une première version très simple, n’utilisant pas de modèle. Le principal inconvénient de cette approche est que si l’interface avec l’utilisateur change (une interface en texte seul, type terminal ou avec avec une autre API graphique, Android par exemple), on ne peut rien (ou presque) réutiliser de cette première application.

On doit au moins définir dans une ou plusieurs classes (ici une seule) le modèle, la partie métier, de l’application. C’est le point de départ qui a été donné. Voici une solution possible.

Il est souvent souhaitable que le code des écouteurs (Listener) reste simple. Aussi, il est préférable de définir des méthodes auxiliaires dans la classe que les écouteurs utilisent. Ceci avait été fait pour "recommencer" qui était utilisée à la fois dans le constructeur (initialiser le jeu) et dans un écouteur (recommencer). On peut aussi le faire pour les deux autres. Voici une solution possible.

Pour ces deux dernières solutions, on parle de modèle passif car c’est le contrôleur qui met à jour le modèle d’une part et la vue (ou les vues) d’autre part. On remarque alors que le traitement qui est fait dans le contrôleur pour jouer est très proche de celui qui est fait dans le modèle pour cocher.

Une autre solution est d’avoir un modèle actif. Dans ce cas le modèle est équipé d’un système d’observateurs : le modèle signale ses modifications à des observateurs (VueMorpion). Un contrôleur n’aura plus qu’à modifier le modèle qui signalera les modifications aux vues sans plus d’intervention du contrôleur. Cette solution permet facilement d’ajouter plusieurs vues. De la même façon, il est facile de définir plusieurs contrôleurs. C’est alors le modèle qui devient central. Notons que les contrôleurs sont enregistrés auprès du modèle. Ainsi quand le jeu est quitté depuis un contrôleur, les autres contrôleurs peuvent aussi être avertis (ControleurMorpion est en quelque sorte un deuxième observateur du modèle à destination des contrôleurs). Dans cette dernière solution, deux vues graphiques simples (sans possiblité de cliquer pour jouer), deux contrôleurs graphiques avec cases à cocher sont définis, la classe MorpionSwing précédente (qui est à la fois Vue et Controleur) et, enfin, une vue textuelle sur le score qui en fin d’une partie annonce les scores sur les parties passées.

Merci de signaler toute erreur ou problème concernant ce document à Xavier Crégut <Prenom.Nom@enseeiht.fr>.
Previous Up Next