[PHP] conditions multiples dans un switch - problème de design pattern

conditions multiples dans un switch - problème de design pattern [PHP] - PHP - Programmation

Marsh Posté le 23-01-2008 à 15:11:42    

:hello:

 

NOTE : pour le problème de design pattern, descendez un peu dans le topic, ici :
http://forum.hardware.fr/hfr/Progr [...] m#t1676944

  

je rencontre un petit problème (dont la solution est surement toute bête, mais... je trouve pas ;) )

 

pour placer dans le contexte je peux résumer comme ça :

 

je dois étudier les mouvements des pieces d'un jeu d'échecs.
Pour résumer dans le cas qui me concerne :

 

- un fou peut se déplacer en diagonale
- une tour peut de déplacer à l'horizontale/verticale.

 

- une dame se déplace en diagonale ET à l'horizontale/verticale.

 

donc une dame est à la fois un fou ET une tour.

 

traduction en PHP :

 
Code :
  1. <?
  2. $a="Fou";
  3. switch($a)
  4. {
  5. case "Dame" :
  6. case "Fou" :
  7. {
  8.  echo "Fou";
  9.  break;
  10. }
  11. case "Dame" :
  12. case "Tour" :
  13. {
  14.  echo "Tour";
  15.  break;
  16. }
  17. default :
  18. {
  19.  echo "rien";
  20. }
  21. }
  22. ?>


Le code ci dessus fait se comporter la dame comme un fou.
si j'enlève les break, alors toutes les pièces sont des dames.

 

Mon but :
- si je mets "Fou" dans la variable $a, cela imprime Fou
- si je mets "Tour" dans la variable $a, cela imprime Tour
- si je mets "Dame" dans la variable $a, cela imprime FouTour

 

Les solutions que j'ai trouvées :
- mettre un case "dame" dans lequel je copie le code de Fou ET Tour. ça marche, mais ça duplique le code, c'est pas très propre.
- mettre un if($a!="Tour" ) dans le case tour, mais c'est encore plus sale.

 


voilà.
je sais pas si c'est très clair, mais si vous pouvez m'éclairer pour faire un truc propre, c'est cool.

 

Merci :jap:


Message édité par nabbo le 25-01-2008 à 19:39:10
Reply

Marsh Posté le 23-01-2008 à 15:11:42   

Reply

Marsh Posté le 23-01-2008 à 15:18:34    

A ta place, j'utiliserais des fonctions. Comme ça, il ne te restera plus qu'a appeller la/les bonne(s) fonction(s) en fonction du cas et tu éviteras toute duplication du code.

Reply

Marsh Posté le 23-01-2008 à 15:20:59    

le truc c'est que je suis déjà dans une fonction qui calcule les déplacements en fonction de la pièce, le tout dans un objet.
 
Ca me parait plus propre, non ? (question sincère... j'essaie d'être propre et lisible.)
 
et puis je suis curieux... le switch doit bien prévoir ce cas, non?
 
d'autres avis ?
 
:jap:

Reply

Marsh Posté le 23-01-2008 à 15:25:00    

ton switch est pourri. Pourquoi fais-tu plusieurs "case" avec les mêmes valeurs?

 
Code :
  1. $a = 'Fou';
  2. switch($a)
  3. {
  4. case "Dame" :
  5.  //traitement pour la dame
  6.  echo "dame";
  7.  ...
  8.  break;
  9. case "Fou" :
  10.  //traitement pour le fou
  11.  echo "Fou";
  12.  ...
  13.  break;
  14. default:
  15.  //traitement par défaut si on ne rentre dans aucune autre condition
  16.  echo "rien";
  17. }

Message cité 1 fois
Message édité par soulmanto le 23-01-2008 à 15:25:44
Reply

Marsh Posté le 23-01-2008 à 15:34:18    

soulmanto a écrit :

ton switch est pourri. Pourquoi fais-tu plusieurs "case" avec les mêmes valeurs?


Tu n'as pas compris le problème....
Il veut assimiler la dame à fou+tour.
Je suis d'accord avec omega2, à mon avis c'est la meilleure solution.


---------------
Feedback : http://forum.hardware.fr/hfr/Achat [...] 2666_1.htm
Reply

Marsh Posté le 23-01-2008 à 15:36:07    

La structure switch n'a jamais été faite pour dire "si 'machin' ou 'truc' alors blabla + ce que fait 'chouette' sauf si 'machin'.
 
Par contre si tu ne mets pas de break alors ça donne bien "si 'machin' ou 'truc' alors blabla + ce que fait 'chouette'" et ça, le switch le gère bien.
 
Pour le fait que t'es déjà dans une fonction : oui et alors? Rien n'empêche d'avoir une fonction qui sert à appeller la bonne fonction en fonction d'une valeur donnée. Si en plus ton objet représente une pièce, alors il aurait été plus propre de faire une classe par type d'objet plutôt qu'une classe générique, même s'il est vrai qu'une partie du code risquerait d'être dupliqué si tu as plusieurs classes différentes.
 
PS : Je ne le dis pas de la même manière, mais je suis d'accord avec soulmanto. D'ailleurs, un switch est comme une suite de "si alors blabla sinon si" et non pas de "si alors blabla fin du si, si alors ..." ce qui veut dire qu'il ne peut jamais y avoir plusieurs label identique.


Message édité par omega2 le 23-01-2008 à 15:40:06
Reply

Marsh Posté le 23-01-2008 à 15:39:16    

en l'occurence, j'ai une classe piece
avec un attribut "type" qui me dit de quelle piece je parle
 
dans cette classe piece j'ai une méthode calculePositions dans laquelle je fais switch($this->type)
 
il faudrait donc que je crée d'autres méthodes genre :
calculePositions_Fou, calculePositions_Dame, calculePositions_Tour, etc
 
???

Reply

Marsh Posté le 23-01-2008 à 15:44:30    

Et heu ... pourquoi ne pas faire des classes "fou", "roi" ... qui dérivent de la classe "piece" générique et qui redéfinissent la fonction "calculePositions"?
Le système d'héritage d'une classe n'a pas été inventé pour des prunes.
 
PS : En passant, jette un oeuil aux motif de conception (design pattern en anglais) : http://fr.wikipedia.org/wiki/Motif_de_conception
http://en.wikipedia.org/wiki/Desig [...] r_science)
Il en existe un qui sert à choisir la bonne classe à partir d'une condition donnée. ;)

Reply

Marsh Posté le 23-01-2008 à 15:45:17    

Citation :

Tu n'as pas compris le problème....
Il veut assimiler la dame à fou+tour.
Je suis d'accord avec omega2, à mon avis c'est la meilleure solution


 
Si, j'ai parfaitement compris ce qu'il veut faire, seulement la façon dont il le traduit en code n'est pas bonne. Chaque pièce est une entité distincte avec ses règles particulières, donc fonctionnellement leurs traitements sont différents.

Reply

Marsh Posté le 23-01-2008 à 16:54:33    

omega2 a écrit :

Et heu ... pourquoi ne pas faire des classes "fou", "roi" ... qui dérivent de la classe "piece" générique et qui redéfinissent la fonction "calculePositions"?
Le système d'héritage d'une classe n'a pas été inventé pour des prunes.
 
PS : En passant, jette un oeuil aux motif de conception (design pattern en anglais) : http://fr.wikipedia.org/wiki/Motif_de_conception
http://en.wikipedia.org/wiki/Desig [...] r_science)
Il en existe un qui sert à choisir la bonne classe à partir d'une condition donnée. ;)


 
 
design pattern... j'ai vu ca à l'école... mais c'est loin ;)
 
ce dont tu parles, c'est le design pattern factory ?
 
si c'est ca, je ne vois pas trop comment l'adapter à mon cas... tu aurais un exemple ?
 
merci :jap:

Reply

Marsh Posté le 23-01-2008 à 16:54:33   

Reply

Marsh Posté le 23-01-2008 à 17:02:19    

Plus exactement, c'est la fabrique abstraite (Abstract Factory)
J'ai la flemme de créer une exemple exprès pour toi alors je te file le liens d'un exemple disponible sur wikipedia : http://fr.wikipedia.org/wiki/Fabri [...] ion%29#PHP
Dans leur cas, ils lisent un fichier de config pour savoir quel bouton créer, dans le tiens, t'auras un paramètre qui te diras quelle pièce créer.

Reply

Marsh Posté le 23-01-2008 à 17:58:04    

Et petit lien qu'il est bien ( from Masklinn, signé de qualité)
http://gsraj.tripod.com/design/cre [...] ctory.html

Reply

Marsh Posté le 23-01-2008 à 19:33:55    

omega2 a écrit :

Et heu ... pourquoi ne pas faire des classes "fou", "roi" ... qui dérivent de la classe "piece" générique (...) Le système d'héritage d'une classe n'a pas été inventé pour des prunes.


 
Dans mes bras !  :love:  
 


---------------
Directeur Technique (CTO)
Reply

Marsh Posté le 23-01-2008 à 19:40:28    


Pas mieux :o


---------------
Always wear a camera!
Reply

Marsh Posté le 24-01-2008 à 11:53:38    


 
j'ai essayé un pattern strategy, avec une interface Ipiece :
 

Code :
  1. interface Ipiece {
  2. public function __construct($x,$y);
  3. public function __destruct();
  4. public function getXpos();
  5. public function getYpos();
  6. public function move($xdest,$ydest);
  7. public function checkMove($board);
  8. }
  9. abstract class piece implements Ipiece {
  10. protected $xpos;
  11. protected $ypos;
  12. protected $nbmoves;
  13. public function getXpos() {
  14.  return $this->xpos;
  15. }
  16. public function getYpos() {
  17.  return $this->ypos;
  18. }
  19. public function move($xdest,$ydest)
  20. {
  21.  $this->xpos=$xdest;
  22.  $this->ypos=$ysdest;
  23.  $this->nbmoves++;
  24. }
  25. public function __construct($x,$y)
  26. {
  27.  $this->xpos=$x;
  28.  $this->ypos=$y;
  29.  $this->nbmoves=0;
  30. }
  31. public function __destruct()
  32. {
  33.  $this->xpos=NULL;
  34.  $this->ypos=NULL;
  35.  $this->nbmoves=NULL;
  36. }
  37. }
  38. class pion extends piece {
  39. public function checkMove($board)
  40. {
  41.  echo 'je vérifie dans $board que je peux avancer';
  42. }
  43. }
  44. class fou extends piece {
  45. public function checkMove($board)
  46. {
  47.  echo 'je vérifie dans $board que je peux aller en diagonale';
  48. }
  49. }
  50. class tour extends piece {
  51. public function checkMove($board)
  52. {
  53.  echo 'je vérifie dans $board que je peux aller en hori/verti';
  54. }
  55. }
  56. class dame extends piece {
  57. public function checkMove($board)
  58. {
  59.  echo 'je vérifie dans $board que je peux aller en hori/verti';
  60.  echo 'je vérifie dans $board que je peux aller en diagonale';
  61. }
  62. }
  63. $mapiece=new dame(1,1);
  64. $mapiece->checkMove('toto');


 
ca vous parait bien ?
 
est ce que dans la classe dame, je suis obligé de recopier la méthode checkMove de fou et de tour ?
 
d'autre part, au niveau conception, comment je peux matérialiser un joueur ?
 
merci :jap:

Reply

Marsh Posté le 24-01-2008 à 11:56:17    

pourquoi faire une classe abstraite qui implémente une interface plutot que de déclarer les méthodes de l'interface comme abstraites dans ta classe abstraite???
(note: je suis pas persuadé que cette phrase soit compréhensible)

Reply

Marsh Posté le 24-01-2008 à 12:05:55    

pas compris :D
 
tentative de réponse : pourquoi pas ?
 
je me suis inspiré d'un script d'implémentation de design pattern strategy ici :
http://classes.scriptsphp.org/arti [...] n-Strategy
 
l'interface : je vois pas encore l'intérêt d'en avoir, sinon de forcer à écrire toutes les méthodes à chaque fois. (même si, si l'on oublie une méthode, on devrait s'en rendre compte assez vite ?)
 
 

Reply

Marsh Posté le 25-01-2008 à 09:47:38    

Je vais la retenter autrement :)
Je vois pas l'interêt de l'interface dans ton précis.
Du coup j'aurais tendance à faire:

Code :
  1. abstract class piece{
  2. protected $xpos;
  3. protected $ypos;
  4. protected $nbmoves;
  5. abstract public function checkMove($board);
  6. [...]
  7. }


L'interface n'a a mon sens d'interêt que si tu as plusieurs "jeux" qui ont des pièce ( par exemple echec, dame, go ...).
A ce moment là, ton interface te permettra de t'assurer que tu disposes des methodes d'une pièce quelque soit sa classe abstraite (piece_echec, piece_dame, piece_go).
 
Une dernière remarque, si 'toto' est un echiquier je suis pas fan de comment tu t'en sers. Pour moi une pièce est sur un et un seul echiquier.
Je me demande si je ferais pas plutôt un builder sur ta classe echiquier.

Reply

Marsh Posté le 25-01-2008 à 10:58:38    

hello

 

non, mon échiquier ne servira pas à jouer aux dame ;)

 


je n'ai pas non plus mon passage d'argument.
j'arrive à un truc genre

 
Code :
  1. $monboard->board[1][2]->calculate_positions($monboard->board);
 

ce qui ne semble pas très propre...

 

qu'entends-tu pas builder ?

 


edit : tu parles probablement du design pattern builder... je me plonge dans wikipedia, et je reviens ;)

 

:jap:


Message édité par nabbo le 25-01-2008 à 12:44:22
Reply

Marsh Posté le 25-01-2008 à 19:30:33    

re - :hello:
 
j'ai essayé quelque chose, en voulant implémenter un design pattern 'composite' (dans l'optique de dire : une case est une partie du tableau, donc il y a une hiérarchie : le design pattern composite semble être adapté dans ce cas.)
 
la source de mon inspiration est là : http://www-igm.univ-mlv.fr/~dr/XPO [...] terns.html (c'est du PHP4, mais je n'en prends que l'idée...)
 
je rajoute donc un attribut $board à mon objet piece, en le plaçant en référence au constructeur de piece.
 
du coup, je me retrouve avec un objet $board, constitué d'un double array de cases pouvant contenir des instances de piece, instances qui contiennent elles mêmes un pointeur vers $board...  
 
c'est là que ça cloche à mon avis.
 
je poste le code, au cas où :
 
classe piece simplifiée :  

Code :
  1. class piece
  2. {
  3. protected $xpos;
  4. protected $ypos;
  5. protected $nbmoves;
  6. protected $player;
  7. protected $board;
  8. public $pos;
  9. public function __construct($x,$y,$player,$board)
  10. {
  11.  $this->xpos=$x;
  12.  $this->ypos=$y;
  13.  $this->nbmoves=0;
  14.  $this->player=$player;
  15.  $this->board=$board;
  16. }
  17. public function move($xdest,$ydest)
  18. {
  19.  $x_src=$this->xpos;
  20.  $y_src=$this->ypos;
  21.  $this->xpos=$xdest;
  22.  $this->ypos=$ydest;
  23.  //je déplace la piece en utilisant son attribut board
  24.  $this->board[$xdest][$ydest]=$this;
  25.  //je supprime l'emplacement ancien de la piece
  26.  unset($this->board[$x_src][$y_src]);
  27.  $this->nbmoves++;
  28. }
  29. public function getType()
  30. {
  31.  return 'piece';
  32. }
  33. }


 
classe board simplifiée :

Code :
  1. class board {
  2. public $board;
  3. protected $p1; //player 1
  4. protected $p2; //player 2
  5. function __construct()
  6. {
  7.   $this->init();
  8. }
  9. function init()
  10. {
  11.  $this->p1='joueur 1';
  12.  $this->p2='joueur 2';
  13.  for($y=8;$y>=1;$y--)
  14.   $this->board[$y]=array();
  15.  //je donne le board en argument, par référence, car (dans ma tête) référence = pas de copie, et pas de copie = j'économise en mémoire ?
  16.  $this->board[1][1]=new piece(1,1,$this->p1, &$this->board);
  17.  $this->board[2][1]=new piece(2,1,$this->p1, &$this->board);
  18.  $this->board[3][1]=new piece(3,1,$this->p1, &$this->board);
  19.  $this->board[4][1]=new piece(4,1,$this->p1, &$this->board);
  20.  $this->board[5][1]=new piece(5,1,$this->p1, &$this->board);
  21.  $this->board[6][1]=new piece(6,1,$this->p1, &$this->board);
  22.  $this->board[7][1]=new piece(7,1,$this->p1, &$this->board);
  23.  $this->board[8][1]=new piece(8,1,$this->p1, &$this->board);
  24.  $this->board[1][2]=new piece(1,2,$this->p1, &$this->board);
  25.  $this->board[2][2]=new piece(2,2,$this->p1, &$this->board);
  26.  $this->board[3][2]=new piece(3,2,$this->p1, &$this->board);
  27.  $this->board[4][2]=new piece(4,2,$this->p1, &$this->board);
  28.  $this->board[5][2]=new piece(5,2,$this->p1, &$this->board);
  29.  $this->board[6][2]=new piece(6,2,$this->p1, &$this->board);
  30.  $this->board[7][2]=new piece(7,2,$this->p1, &$this->board);
  31.  $this->board[8][2]=new piece(8,2,$this->p1, &$this->board);
  32.  $this->board[1][8]=new piece(1,1,$this->p2, &$this->board);
  33.  $this->board[2][8]=new piece(2,1,$this->p2, &$this->board);
  34.  $this->board[3][8]=new piece(3,1,$this->p2, &$this->board);
  35.  $this->board[4][8]=new piece(4,1,$this->p2, &$this->board);
  36.  $this->board[5][8]=new piece(5,1,$this->p2, &$this->board);
  37.  $this->board[6][8]=new piece(6,1,$this->p2, &$this->board);
  38.  $this->board[7][8]=new piece(7,1,$this->p2, &$this->board);
  39.  $this->board[8][8]=new piece(8,1,$this->p2, &$this->board);
  40.  $this->board[1][7]=new piece(1,2,$this->p2, &$this->board);
  41.  $this->board[2][7]=new piece(2,2,$this->p2, &$this->board);
  42.  $this->board[3][7]=new piece(3,2,$this->p2, &$this->board);
  43.  $this->board[4][7]=new piece(4,2,$this->p2, &$this->board);
  44.  $this->board[5][7]=new piece(5,2,$this->p2, &$this->board);
  45.  $this->board[6][7]=new piece(6,2,$this->p2, &$this->board);
  46.  $this->board[7][7]=new piece(7,2,$this->p2, &$this->board);
  47.  $this->board[8][7]=new piece(8,2,$this->p2, &$this->board);
  48. }
  49. function out()
  50. {
  51.  echo "<table border='1'> \n";
  52.  echo '<tr><td colspan="9">'.($this->p2)."</td></tr>\n";
  53.  for($y=8;$y>=1;$y--)
  54.  {
  55.   echo "<tr>\n";
  56.   echo "\t<td>".$y."</td>\n";
  57.   for($x=1;$x<=8;$x++)
  58.   {
  59.    if(($x+$y)%2==0)
  60.     $bg="silver";
  61.    else
  62.     $bg="white";
  63.    if(@$this->board[$x][$y])
  64.    {
  65.     $piece=$this->board[$x][$y]->getType();
  66.     echo "\t<td style='background-color: ".$bg.";'>".$piece."</td>\n";
  67.    }
  68.    else
  69.     echo "\t<td style='background-color: ".$bg.";'></td>\n";
  70.   }
  71.   echo "</tr>\n";
  72.  }
  73.  echo '<tr><td>&nbsp;</td>';
  74.   for($x=1;$x<=8;$x++)
  75.    echo '<td>'.chr($x+64).'</td>';
  76.  echo '</tr>';
  77.  echo '<tr><td colspan="9">'.($this->p1)."</td></tr>\n";
  78.  echo "</table>\n";
  79. }
  80. }


 
 
et pour tester on peut coller ca à la fin du fichier qu'on appelle classes.php:
 

Code :
  1. $monboard=new board();
  2. if (isset($_POST['move_from'], $_POST['move_to']))
  3. {
  4. 'Move from '.$_POST['move_from'].' to '.$_POST['move_to'];
  5. $x_src=$_POST['move_from']{0};
  6. $y_src=$_POST['move_from']{1};
  7. $x_dst=$_POST['move_to']{0};
  8. $y_dst=$_POST['move_to']{1};
  9. //ceci ne marche pas très bien
  10. $monboard->board[$x_src][$y_src]->move($x_dst,$y_dst);
  11. }
  12. $monboard->out();
  13. ?>
  14. <form action="classes.php" method="post" id="formsend">
  15. from : <input type="text" id="move_from" name="move_from"><br />
  16. to : <input type="text" id="move_to" name="move_to">
  17. <input type="submit" value="go" />
  18. </form>


 
 
voilà. j'ai épuré le code, mais le principe est là.
si quelqu'un peut m'aider, ca serait sympa.
 
euh... je rappelle ma question [:priareos] :
- est ce qu'il faut bien implanter un design pattern composite,  
       - si oui, est ce que mon composite est bien implanté (j'en doute...)
       - si non, qu'est ce qui cloche ?
-si non, quel est le design pattern pour mon cas ?
 
merci :jap:


Message édité par nabbo le 25-01-2008 à 19:32:47
Reply

Marsh Posté le 25-01-2008 à 19:39:37    

oui, mais alors comment faire ?

Reply

Marsh Posté le 25-01-2008 à 19:44:06    

j'ai fait des schémas sur papier
pour le nommage... c'est pas trop un problème (enfin le problème n'est pas là)
pour les joueurs, je pensais faire une classe partie, mais que je ferai plus tard.
 
pour l'instant je veux juste modéliser les pieces et leur déplacement
 
et donc je cherche le design pattern le plus adapté à mon cas  :(


Message édité par nabbo le 25-01-2008 à 19:46:28
Reply

Marsh Posté le 25-01-2008 à 20:01:45    

c'est quand même pas sorcier.
Note préliminaire : le PHP j'y pipe rien, la c'est un probleme purement objet, a toi (ou à vous les autres posteurs) de mettre le nom de la classe de base qui va bien la ou il faut.

 

Les entités en présence :

 

Joueur
Case
Equiquier
Piece
Partie

 

Les relations :

 

Une Partie contient :
2 Joueurs
1 Echiquier
2*12 Piéces

 

Un Echiquier contient
une collection de 8*8 cases

 

Un case contient :
un pointeur vers la Piéce qui est dessus (potentiellement NULL)

 

Une piéce contient
un pointeur vers le joueur à qui elle appartient

 

Première étape : comment tou ça dialogue-t-il ?
* Un joueur peut bouger une pièce en appelant la méthode move() de la piéce
a qui il passe la case de destination.

 

* Lorsque une piéce bouge, elle prend sa case de destination
et vérifie si le mouvement est valide. Si il est , elle se déplace
(elle s'enleve de sa case et va vers la case destination)

 


Deuxième étape : Comment une piéce sait elle si son deplacement est valide
Pour chaque type de déplacement élémentaire (tout droit, en diagonale, de une case seulement etc)
tu creer une classe Mouvement qui contient une methode check() qui renvoit un bool qui dit si oui ou non
le mouvement est valide en prenant en argument la case source et la case destination.
Ensuite, chaque piece contient une liste de Mouvement. La méthode check de la pièce appelle donc en séquence
les check() de ses mouvements et les combine avec un ET logique.

 

Chaque pièce recoit à la construction le ou les Mouvement qui lui sont associés.

 

En gros tu as besoin :

 

* d'une factory pr creer tes piéces
* la liste de mouvement implante Strategy
* Je mettrais bien un flyweight pr gérer les stratégies sans les dupliquer.

Message cité 1 fois
Message édité par Joel F le 26-01-2008 à 10:22:24
Reply

Marsh Posté le 25-01-2008 à 20:08:38    

C'est ici, la fabriquation d'usines à gaz?


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 25-01-2008 à 21:04:28    

je vois pas ce qui t'embete [:dawa]

Reply

Marsh Posté le 25-01-2008 à 21:06:55    

Absolument pas tant qu'on me demande pas d'implémenter cette horreur [:dawa]


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 26-01-2008 à 10:21:58    


 
oui, c'est flyweight. Ma fourche à languer, c'est bien de ça dont je veux parler.
Je retro-corrige

Reply

Marsh Posté le 26-01-2008 à 12:25:04    

Joel F a écrit :

c'est quand même pas sorcier.  
Note préliminaire : le PHP j'y pipe rien, la c'est un probleme purement objet, a toi (ou à vous les autres posteurs) de mettre le nom de la classe de base qui va bien la ou il faut.
 
Les entités en présence :
 
Joueur
Case
Equiquier
Piece
Partie
[...]


 
je vais essayer de comprendre tous le message (surtout la fin, parce que pour le début, on est bien d'accord), puis je ferai un dessin ;)
merci pour ton aide.
 
 

masklinn a écrit :

C'est ici, la fabriquation d'usines à gaz?


euh... tu as une idée pour faire plus simple.
 
PS : effectivement, le PHP osef pour l'instant. on parle bien de conception, et si je m'en sors bien, le PHP (ou autre) passera sans problème.
 
:jap:

Reply

Marsh Posté le 26-01-2008 à 14:00:21    

nabbo a écrit :


euh... tu as une idée pour faire plus simple.

 

PS : effectivement, le PHP osef pour l'instant. on parle bien de conception, et si je m'en sors bien, le PHP (ou autre) passera sans problème.

 

:jap:


Ne pas faire un objet complet de chaque pièce, ça n'a aucun intérêt dans la mesure où les pièces ne sont pas des agents intelligents mais des marqueurs explicitement manipulés par un agent externe (que tu peux voir soit comme le plateau, soit comme le joueur, soit comme le joueur par l'intermédiaire du plateau). Donc perso je modéliserais les pièces comme de simple dataholders pour deux éléments (au mieux), le type (de pièce, au sens dame/fou/roi/autre, juste pour pouvoir l'afficher correctement) et les contraites de déplacement. Point barre, et c'est le tableau qui, sur ordre de déplacement d'un joueur, vérifie que le déplacement respecte les contraintes de la pièce.

 

Je ne vois absolument pas quel logique pourrait être intéressante dans la pièce, à part "aucune".

 

edit: ah si, on peut lier un "widget" aux pièces pour qu'elles sachent comment s'afficher, mais c'est pas de la logique "métier".

Message cité 2 fois
Message édité par masklinn le 26-01-2008 à 14:01:57

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 26-01-2008 à 14:08:37    

masklinn a écrit :


Ne pas faire un objet complet de chaque pièce, ça n'a aucun intérêt dans la mesure où les pièces ne sont pas des agents intelligents mais des marqueurs explicitement manipulés par un agent externe (que tu peux voir soit comme le plateau, soit comme le joueur, soit comme le joueur par l'intermédiaire du plateau). Donc perso je modéliserais les pièces comme de simple dataholders pour deux éléments (au mieux), le type (de pièce, au sens dame/fou/roi/autre, juste pour pouvoir l'afficher correctement) et les contraites de déplacement. Point barre, et c'est le tableau qui, sur ordre de déplacement d'un joueur, vérifie que le déplacement respecte les contraintes de la pièce.
 
Je ne vois absolument pas quel logique pourrait être intéressante dans la pièce, à part "aucune".
 
edit: ah si, on peut lier un "widget" aux pièces pour qu'elles sachent comment s'afficher, mais c'est pas de la logique "métier".


 
 
oui, dans ma conception de départ, c'était le plateau qui déplacait les pieces, et qui vérifait les positions possibles.
les pieces n'avaient que des attributs, dont leur nom, leur position actuelle et leurs positions possibles calculées à la demande du plateau.
 

Reply

Marsh Posté le 26-01-2008 à 14:21:57    

nabbo a écrit :


 
 
oui, dans ma conception de départ, c'était le plateau qui déplacait les pieces, et qui vérifait les positions possibles.
les pieces n'avaient que des attributs, dont leur nom, leur position actuelle et leurs positions possibles calculées à la demande du plateau.
 


Tu comptes créer un bot jouant aux échecs ou pas?


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 26-01-2008 à 14:27:29    

oui, c'est prévu

 

edit : ca changerait quoi selon toi ?

Message cité 1 fois
Message édité par nabbo le 26-01-2008 à 14:43:14
Reply

Marsh Posté le 26-01-2008 à 15:05:21    

nabbo a écrit :

oui, c'est prévu
 
edit : ca changerait quoi selon toi ?


Que s'il y a des bots il faut pouvoir calculer les mouvements possibles des pièces, alors que s'il n'y a pas de bot il faut juste calculer qu'un mouvement est valide (c'est pour ça que je parlais de stocker des contraintes, j'étais parti du principe qu'il n'y avait pas de bot)


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 26-01-2008 à 15:12:07    

en fait, je calcule les positions possibles :
- pour aider "l'utilisateur novice" à savoir où il peut bouger pour une pièce donnée
- ensuite, comme j'ai stocké les positions possibles dans un tableau qui est un attribut de mon objet piece, je n'ai qu'à vérifer, après mouvement, que celui ci est dans la liste des mouvements possibles.
- et, effectivement, cela me permettra (je pense) de simplifier les choses avec un bot
 
le bot n'est qu'un projet d'évolution que je garde en tête. je pense que dans mon schéma de départ, c'est la classe joueur et la classe partie qui vont changer. les mouvements et le plateau restent les mêmes.

Reply

Marsh Posté le 26-01-2008 à 15:27:49    

masklinn a écrit :


Donc perso je modéliserais les pièces comme de simple dataholders pour deux éléments (au mieux), le type (de pièce, au sens dame/fou/roi/autre, juste pour pouvoir l'afficher correctement) et les contraites de déplacement. Point barre, et c'est le tableau qui, sur ordre de déplacement d'un joueur, vérifie que le déplacement respecte les contraintes de la pièce.


 
qu'est ce que tu appeles un dataholder ?
ca reste un objet au sens poo ?
 
c'est à dire une instance de classe avec des attributs et pas (ou peu) de méthodes ?
 

Reply

Marsh Posté le 26-01-2008 à 15:40:18    

nabbo a écrit :


 
qu'est ce que tu appeles un dataholder ?
ca reste un objet au sens poo ?
 
c'est à dire une instance de classe avec des attributs et pas (ou peu) de méthodes ?
 


Oui, c'est équivalent à une struct C ou un record, c'est un objet/une classe qui n'existe que pour stocker des données mais n'a pas de comportement (méthodes, messages, ...)


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed