gfive | bah....Dans un cas comme ça, il faut que tu réfléchisses de façon plus "objet", je dirais : Il te faut : - Une classe "modèle d'échiquier", qui sait où sont les pièces, - Une classe "echiquier" qui sait dessiner l'échiquer : elle demande au modèle les pièces à dessiner, puis donne à chaque pièce son context graphique, et lui "demande" de se dessiner dessus...
Perso, je ferais un truc du stye :
Code :
- public class Echiquier extends Cancas {
- private ModeleEchiquer model;
- ...
- public void dessineEchiquier(Graphics g) {
- // Dessine les cases blanches et noires, et les lignes
- }
- public Rectangle getCell(int x, int y) {
- //retourne le rectangle (objet de java.awt) qui représente la case (x,y) de l'échiquier : dépend par conséquent de la taille d'affichage, de la largeur des lignes, etc..)
- }
- public void paint(Graphics g) {
- dessineEchiquer(g);
- Piece piece;
- Rectangle case;
- for (int i = 0; i < model.getPieces(); i++) {
- piece = model.get(i);
- case = getCell(piece.getX(), piece.getY();
- g.setClip(case);
- piece.draw(g, case.x, case.y);
- }
- }
- }
- public interface Piece {
- public int getX();
- public int getY();
- public void draw(Graphics g, int base_x, int base_y);
- }
|
Bon, après, le "for" est sans doute pas ce qu'on fait de mieux, mais c'est pas le point important dans ce design...L'important, c'est de bien séparer la "symbolique" (emplacement de la pièce, propriétaire, etc...géré dans le modèle, et dans les implémentations de l'interface pièce) et le dessin de l'échiquier, qui ne doit pas dépendre des pièces : il se fait toujours de la même façon..
Pour être rigoureux, il faudrait même 2 interfaces pour la pièce : une qui contient ses données (position, déplacements possibles à partir de la position, couleur, etc..) et une qui sait comment dessiner sa représentation à l'écran.
ouala ouala.. |