[Conception] Concevoir le jeu Pierre Feuille Ciseau

Version imprimable

15/03/2006, 18h57
websurfeur

[Conception] Concevoir le jeu Pierre Feuille Ciseau

Bonjour,

Je suis étudiant en licence informatique et dans le module de programmation orienté objet (avec comme langage de support Java) je dois modelisé un ensemble d'objet (classe ou interface mais sans héritage) pour le problème du jeu pierre feuille ciseau.

Il faut pouvoir tiré aléatoirement soit la pierre ou la feuille ou le ciseaux et appliquer les régles élémentaires de ce jeu.

Je me permet de poster un message sur ce forum, car pour avoir réfléchis longement à la question je ne vois pas du tout comment faire. :(

Merci d'avance pour votre aide.
15/03/2006, 19h32
professeur

Salut!

Pour ce type de jeu je vois trois interfaces:
- Player : représente les actions d'un joueur (tirage, notification de la partie, interactions,...)
- Game : représente la partie en cours, il contient les joueurs et la règle du jeu. C'est le moteur du jeu (schedule, dispatche,...)
- Rule : représente la règle du jeu. Le fait de spécifier une interface Rule indépendemment du moteur permet de modifier les regles du jeu sans toucher au moteur ni de tout repenser...

A+

mouaif .. perso je pense que tu y es allé 1 peu fort avec les interfaces professeur .... jte fais 1 ptite analyse et je ré-éditerai ce message dans 10 minutes ...

Bon .. voilà :
Tout d'abord, pas d'héritage en Java, tu dira à ton prof que ça n'exiqte pas, sauf pour les types primitifs : toute variable de type non primitif hérite forcément de la classe Object, et tu peux t'en servir.

moi je pense que tu pourrais tout d'abord avoir une classe Game, ta classe principale (singleton ? pourquoi pas ...). Cette classe définirait (ou demanderai de saisir, c'est pareil), le nombre de joueurs et leurs nom par exemple... enfin .. tout ce dont tu as besoin pour mettre en place le jeu (juste le jeu .. le reste viendra).
Une fois cela fait, tu crée 'n' Joueur(j'explique comment ils sont définis juste après). Puis, une fois que les joueurs sont créés, tu fais une boucle de jeu (condition d'arrêt à définir : saisie d'1 volonté de continuer ou nombre de tours définis à l'avance ....).
Tu met une méthode main qui instancie un objet de cette classe.

Ensuite vient la classe Joueur. Elle contient un tableau static de 3 'Object' à instancier comme ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 public class Joueur { public static int NB_ARMES = 3; public static Object[] armes; static { armes = new Object[NB_ARMES]; }//bloc appelé une sele fois dans toutes les utilisations de la classe .....
Ainsi tous toutes les armes seront communes aux joueurs.
voilà pour Joueur.

Ensuite ... on peut en effet créer une Interface Rule qui impose à toute classe l'implémentant de déterminer une règle de priorité sur un elément qu'on lui fournit .... bien que .... l'interface Comparable impose déjà (et uniquement) ce traitement ... je pencherai donc pour :

trois classes "d'armes" distinctes :
Code:

1 2 3 4 5 6 7 public class Pierre implements Comparable { ...... public void compareTo(Object o){ ....//test comparatif : instanceof et compagnie ... } }
Code:

1 2 3 4 5 6 7 public class Feuille implements Comparable { ...... public void compareTo(Object o){ ....//test comparatif : instanceof et compagnie ... } }
Code:

1 2 3 4 5 6 7 public class Ciseaux implements Comparable { ...... public void compareTo(Object o){ ....//test comparatif : instanceof et compagnie ... } }
En théorie, c'est tout ce dont tu as besoin et ça fonctionne ...
dsl .. G mis du temps à taper tout ce post ^^

15/03/2006, 21h46
Gfx

En tout cas cela ressemble a un exemple parfait d'application du pattern "type-safe enum" (voir livre Effective Java, Google ou tout betement le nouveau mot-cle enum de Java 1.5).
16/03/2006, 09h26
websurfeur

Tout d'abord merci pour vos réponses rapides !

Donc si j'ai bien compris, je vais ranger mes objets Pierre Feuille Ciseau qui implementes tous Comparable dans le tableau de type Object : armes !

Et pour faire un tirage aléatoire de l'objet je fais un Math.ramdom() entre 0 et 3 sur l'index du tableau !

Je ne comprends pas très bien l'utilité de mettre en static le tableau.

Ha oui encore une chose : comment se fait-il que je n'ai jamais entendu parler (dans des bouquins, ou ailleurs ) du bloc static car ça à l'air utile (c un peu la même utilité qu'en langage C).
16/03/2006, 10h16
Regis.C
Une methode static permet d'appeler la methode à partir de la classe directement sans avoir à instancier d'objet.
Quel que soit le nombre d'instance, une methode static est executée via le nom de ta classe :
Code:

1 2 3 4 5 class MonStatic { public static void essai() {} }
Appel de la methode :

Code:

MonStatic.essai();

Un attribut static, lui, est invariable dans le temps quel que soit le nombre d'objet instancié de la classe dans laquelle il existe.
Un tableau de 100 élements de type static fera toujours 100 élements pour tous les objets instanciés de cette classe.
16/03/2006, 10h35
Deadpool

Juste pour compléter/corriger la réponse de Regis C., l'intérêt d'un attribut statique est qu'il est partagé par toutes les instances d'une même classe.

Et non il n'est pas invariant, ça n'a rien à voir, tu confond avec final là.

Je vous remercie de votre aide mais j'ai trouvé un solution qui se présente sous cette forme :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
 
public class Pierre implements Comparable 
{
 
	/**
         * Retourne -1 si l'objet est battu, 0 s'il sont égaux, 1 s'il l'objet bas l'autre. 
         */
	public int compareTo(Object o)
	{
		if(o instanceof Pierre)
			return 0;
		if (o instanceof Feuille)
			return -1;
		//if (o instanceof Ciseau)
		return 1;
	}
 
}
/* ---------------------------------------- */
public class Feuille implements Comparable
{
	public int compareTo(Object o)
	{
		if (o instanceof Feuille)
			return 0;
		if (o instanceof Ciseau)
			return -1;
		//if (o instanceof Pierre)
		return 1;
	}
 
}
/* ---------------------------------------- */
public class Ciseau implements Comparable {
 
	public int compareTo(Object o) 
	{
		if( o instanceof Ciseau)
			return 0;
		if(o instanceof Pierre)
			return -1;
		return 1;
	}
}
/* ----------------------   Classe Joueur représentant un joueur avec son score -----------------------*/
public class Joueur implements Comparable {
 
	private int score;
	private int numJoueur;
	public static int nombreJoueur = 0;
 
	public Joueur()
	{
		this.score = 0;
		this.numJoueur = Joueur.nombreJoueur++;
	}
	public void incrementerScore() { this.score++; }
 
	/**
         * 
         * @param o Object (de type Joueur) à comparer.
         * @return <ul><li>-2 type de l'objet non adapté.</li><li>-1 si le score de l'objet en cours est inférieur</li><li>0 si les objets sont égaux</li><li>1 si l'objet est supérieur au paramètre</li></ul>
         */
	public int compareTo(Object o)
	{
		if ( ! (o instanceof Joueur) )
			return -2;
		Joueur j = (Joueur)o;
		if (this.score == j.score)
			return 0;
		if(this.score < j.score)
			return -1;
		return 1;
	}
 
	public int getCoupAleatoire()
	{
		return (int)(Math.random()*10)%3;
	}
 
	public String toString()
	{
		return "Le joueur n° " + this.numJoueur + " a " + this.score + " points";
	}
}
/*----------------------- Enfin la classe Game --------------------- */
/**
 * Classe "Pillier", c'est celle qui contient le main et permet de lancer le jeu.
 */
public class Game {
 
	private int NB_TOURS = 10;
	private Joueur j1,j2;
	private Comparable [] ensemble;
 
	public Game(Joueur j, Joueur jo)
	{
		this.ensemble = new Comparable[3];
		this.ensemble[0] = new Pierre();
		this.ensemble[1] = new Feuille();
		this.ensemble[2] = new Ciseau();
		this.j1 = j;
		this.j2= jo;
	}
 
	public void jouer()
	{
		while( this.NB_TOURS != 0)
		{
			int coupJ1 = j1.getCoupAleatoire();
			int coupJ2 = j2.getCoupAleatoire();
			switch( this.ensemble[coupJ1].compareTo(this.ensemble[coupJ2]))
			{
				case -1: 
					j2.incrementerScore();
					System.out.println(j2 + " pour avoir joueur : " +this.afficherType(coupJ2) + " contre " + this.afficherType(coupJ1));
					break;
				case 0:
					System.out.println("Egalité les deux joueurs ont joué : " + this.afficherType(coupJ2));
					break;
				case 1: 
					j1.incrementerScore();
					System.out.println(j1 + " pour avoir joueur : " +this.afficherType(coupJ2) + " contre " + this.afficherType(coupJ1));
					break;
			}
			this.NB_TOURS--;
		}
		this.gameOver();
	}
 
	private void gameOver()
	{
		System.out.println();
		System.out.println("-------------- Fin du jeu --------------");
		System.out.println("Récapitulatif des scores : ");
		System.out.println("\t" + this.j1 + "\n\t" + this.j2);
		System.out.println("----------------------------------------");
	}
 
	private String afficherType(int index)
	{
		if(this.ensemble[index] instanceof Pierre)
			return "Pierre";
		if(this.ensemble[index] instanceof Feuille)
			return "Feuille";
		return "Ciseau";
	}
 
	public static void main(String[] args) 
	{
		Joueur a = new Joueur();
		Joueur b = new Joueur();
		Game g = new Game(a,b);
		g.jouer();
	}
}

PS : Une remarque d'ordre général : domage que la couleur des codes soit en vert, car ce n'est pas très agréable à lire.

Voilà c tout !

16/03/2006, 14h22
NeptuS
mon Dieu mon Dieu mon Dieu ..... on ne le répètera jamais assez ... trop de this tue le vice .... euu .. le this pardon :D
Code:

1 2 3 4 this.ensemble = new Comparable[3]; this.ensemble[0] = new Pierre(); this.ensemble[1] = new Feuille(); this.ensemble[2] = new Ciseau();
Donnes moi une seule bonne raison de marquer "this" là où tu l'a fait ?

Perso, je trouve ça très peu lisible. Pour ma part, je n'utilise le pointeur "this" que quand il est indispensable.
16/03/2006, 14h26
bidi

ben ça a l'avantage de mettre tes variables d'instance en évidence, c pas mal moi je trouve :-)
16/03/2006, 14h35
NeptuS

en évidence par rapport à quoi ?

Encore tu aurait déclaré une variable d'instance ensemble et passé un paramètre ensemble, je dis pas ... mais franchement .. là ....

Et puis moi de toutes façons tous mes paramètres nom nommées de cette façon : pEnsemble (p+nom avec une majuscule) Ainsi je ne me trompe jamais de variable.
Rappelez vous une des premières règles de programmation concernant la lisibilité du code : les variables doivent porter des noms significatifs ....
16/03/2006, 14h43
bidi

bha il n'y a pas de règles en java pour les variables d'instance et les params... perso je place this devant ttes mes vars d'instance et "in" devant ts mes params mais c chacun comme il veut ;-) du moment que tu reste cohérent ds tout ton code...
16/03/2006, 15h46
professeur

Salut!

Pour revenir à la définition du jeu, j'utiliserais personnellement des entiers (dans le noyau fonctionnel) pour coder les éléments du jeu:

1 ==> Feuille
2 ==> Ciseau
3 ==> Pierre,
l'intérêt des entiers est qu'ils sont parfaitement faciles à comparer et pour la présentation (l'affichage) du jeu je ferai simplement un formatage (mapping). Ceci permet de remplacer les éléments du jeu par d'autres classes d'éléments (Fusil, pistolet, bombe) sans implémenter les classes mais juste faire un formatage.
D'après ce que l'on m'a appris il faut séparer la présentation visuelle (la vue) de la spécification du noyau fonctionnel.

Peut être que je me trompe. Qu'en pensez-vous?

A+
16/03/2006, 16h09
Deadpool
Bah, s'il utilise Java 1.5, il peut même utiliser les enums (comme Gfx le disait).
Code:

1 2 enum Coups { PIERRE, PAPIER, CISEAUX };
Les enums sont également facile à comparer (on peut même les utiliser dans des switch).
17/03/2006, 20h26
Regis.C

Citation:

Envoyé par Descent

Juste pour compléter/corriger la réponse de Regis C., l'intérêt d'un attribut statique est qu'il est partagé par toutes les instances d'une même classe.

Et non il n'est pas invariant, ça n'a rien à voir, tu confond avec final là.

Au temps pour moi...je voulais d'avantage dire qu'il est commun à chaque construction d'un nouvel objet.
On peut évidement modifier l'attribut par une methode set, ou directement par l'appel de la classe si en plus d'être static l'attribut est public.

Merci pour la correction. :wink: