Conception simple d'une classe "évolutive"

Bonsoir,

N'étant pas très aguerri en JAVA, je viens à vous pour la conception d'une classe.

CONTEXTE :

Un jeu de puzzle constitué d'un ensemble de pièce d'une forme déterminé.
Dans le cadre du projet, la forme de la pièce est un carré.
Je souhaiterai, dans le cas où nous aurions plusieurs formes, obtenir la "modélisation" la plus propre.

IDÉE :

Une Interface "Forme" qui définit des attributs et méthodes communes aux classes forme1, forme2, forme3.
On aurait alors forme1, forme2, forme3 qui implémenteraient l'interface Forme et qui par conséquent définirait les attributs/méthodes issus de l'interfaces.
Par exemple la méthode "rotation" se trouverai dans forme1, forme2, forme3 codé différemment.

Sauf que là je bloque puisque la class Pièce ne peut pas hérité de plusieurs formes (normal),
du coup je ne vois pas comment faire lié différentes formes à la class Pièce à la manière de JAVA.

Ce soucie est une notion de ce langage où j'ai du mal à comprendre,
Pourriez vous m'aidez ?

Merci :D

Si je comprend bien, tu prend le problème à l'envers. Tu as plusieurs formes, qui sont des pièces. Donc tu devrais avoir un interface pièces, qui définit les ce qu'on peux faire avec une pièce (tourner, bouger, etc). Ensuite, tu l'impose pente dans une classe abstraite, qui implémentés les méthodes communes qui s'exécute de la même manière et défini les attributs communs. Chaque pièce de forme différente étends ensuite cette classe en concrétisant ces méthodes, et en en ajoutant d'autres qui lui sont propre. Si les formes ont des méthodes que les pièces n'ont pas, tu peux rajouter un interface forme, et soit l'implementer dans ta classe abstraite, soit dans les concrètes s'il n'y a pas de points communs.

Salut,

La forme est un attribut de la pièce : elle ne peut avoir qu'une seule forme à fois n'est-ce-pas ?

A noter qu'une Interface n'a pas d'attribut. Tu peux utiliser une abstraction pour faire ça (abstract class, mais attention, si une classe peut implémenter plusieurs interfaces, elle ne peut hériter que d'une classe, abstraite ou pas). Par contre, pourquoi la méthode rotation serait différente selon la forme ? Une rotation, c'est une rotation !?

Sache par ailleurs qu'il existe une Interface Shape en Java. Elle ne porte pas directement de méthode rotation, qui changerait la forme elle-même (il y en a une qui créé un PathIterator pour n'importe quelle transformation, dont les rotations donc), mais on peut faire une abstraction à partir de cette classe (ce qui permet d'implémenter très facilement le dessin de la pièce par la suite), et traiter l'instance de Shape par encapsulation.

Par exemple :

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

public abstract class Forme implements Shape {   private Shape shape;   public Forme(Shape shape) { this.shape=shape; }   public void rotation(double theta) { Rectangle2D bounds = getBounds2D(); shape = AffineTransform.getRotateInstance(theta, bounds.getCenterX(), bounds.getCenterY()).createTransformedShape(shape); }   @Override public Rectangle getBounds() { return shape.getBounds(); }   @Override public Rectangle2D getBounds2D() { return shape.getBounds2D(); }   @Override public boolean contains(double x, double y) { return shape.contains(x, y); }   @Override public boolean contains(Point2D p) { return shape.contains(p); }   @Override public boolean intersects(double x, double y, double w, double h) { return shape.intersects(x, y, w, h); }   @Override public boolean intersects(Rectangle2D r) { return shape.intersects(r); }   @Override public boolean contains(double x, double y, double w, double h) { return shape.contains(x, y, w, h); }   @Override public boolean contains(Rectangle2D r) { return shape.contains(r); }   @Override public PathIterator getPathIterator(AffineTransform at) { return shape.getPathIterator(at); }   @Override public PathIterator getPathIterator(AffineTransform at, double flatness) { return shape.getPathIterator(at, flatness); }   }

---

Code:

---

1 2 3 4 5 6 7

public class Carre extends Forme {   public Carre(double cote) { super(new Rectangle2D.Double(0,0,cote,cote)); }   }

---

Et

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Piece {   private Forme forme;   public Piece(Forme forme) { this.forme=forme; }   public Forme getForme() { return forme; }   }

---

Donc on pourra faire :

Code:

---

1 2 3

Piece piece1 = new Piece(new Carre(50)); Piece piece2 = new Piece(new Forme1()); ...

---

Il existe par ailleurs une classe Java qui réprésente n'importe quelle forme, et qui a une méthode rotation (plus exactement tranform()) : Path2D.

Pour les pièces d'un puzzle, comme chaque pièce doit avoir chaque côté identique à celui de la pièce adjacente (à part les bords), on pourrait imaginer une classe Forme qui serait l'assemblage de 4 côtés, qui eux même sont des "courbes", qu'on pourrait modéliser par Path2D par exemple). Ce qui permettrait de générer aléatoirement les pièces d'un puzzle (au bord, le côté serait un segment, mais les autres seraient générés aléatoirement, par paire de pièces adjacente), mais surtout de tester si 2 pièces peuvent se placer l'une à côté de l'autre.

Merci pour vos réponses Cafeinoman et joel.drigo !

Eh beh, joel.drigo tu n'es pas modérateur pour rien, sacré réponse ! :mrgreen:
Comme tu l'as deviné, effectivement une pièce n'a qu'une seule forme à la fois.
Pour un puzzle donnée chaque pièce auront la même forme, désolé de ne pas l'avoir précisé il était tard ...

Citation:

---

Par contre, pourquoi la méthode rotation serait différente selon la forme ? Une rotation, c'est une rotation !?

---

J'ai pris un mauvais exemple. Enfaite, j'imagine qu'il est possible qu'une méthode commune aux formes pourra être différent en fonction de la forme.
En regardant ton code je me suis dit qu'au pire si j'étais confronté à ce cas là je pourrais, après avoir instancié une Pièce, utilisé une méthode "foo" qui ferai un "instanceOf" afin d’exécuter un code précis en fonction de la forme.

Je ne connais en revanche ni PathIterator ni Path2D donc je vais jeté un coup d'oeil !
Sur cette exemple,
Pièce jointe 173129
on remarque 4 pièces composé de 4 faces chacune.
Dans le projet il est conseillé "en gros" de voir le puzzle comme une matrice de pièce du coup ici [1][1]
où l'on aurait juste à comparé "l'id" de la face ( ou le côté ) avec quelque chose du genre puzzle.getPiece(0,0).getId(EST) == puzzle.getPiece(1,0).getId(OUEST) pour comparé si les id adjacents sont égaux.

Citation:

---

on pourrait imaginer une classe Forme qui serait l'assemblage de 4 côtés, qui eux même sont des "courbes", qu'on pourrait modéliser par Path2D par exemple).

---

Donc, si j'ai bien compris, pour toi il y aurai possibilité de pouvoir modélisé les côté (ou face) d'une pièce délimité par des "courbes" avec Path2D ?

Citation:

---

Ce qui permettrait de générer aléatoirement les pièces d'un puzzle (au bord, le côté serait un segment, mais les autres seraient générés aléatoirement, par paire de pièces adjacente), mais surtout de tester si 2 pièces peuvent se placer l'une à côté de l'autre.

---

Ah, là je te suis plus mais c'est parce que je ne connais pas encore ces classes ^^

En tout cas je te remercie pour tes bouts de codes car j'avais connaissances d'une Interface Shape dans la javadoc mais j'ai eu du mal à l'utiliser ... Du coup maintenant je comprends beaucoup mieux !

Merci