JAVA - Constructeur variable???
Fermé
Cire
-
31 mars 2005 à 22:52
choubaka Messages postés 39420 Date d'inscription jeudi 4 avril 2002 Statut Modérateur Dernière intervention 19 février 2025 - 6 avril 2005 à 07:51
choubaka Messages postés 39420 Date d'inscription jeudi 4 avril 2002 Statut Modérateur Dernière intervention 19 février 2025 - 6 avril 2005 à 07:51
A voir également:
- JAVA - Constructeur variable???
- Waptrick java football - Télécharger - Jeux vidéo
- Jeux java itel football - Télécharger - Jeux vidéo
- Java apk - Télécharger - Langages
- Waptrick java voiture - Télécharger - Jeux vidéo
- Java décompiler - Télécharger - Langages
8 réponses
Ce que tu fais s'appelle une "factory", c'est un "design pattern", c'est bien !!!
Pour ton soucis, un bête "if then else", voire un switch (ça marche avec les string, en Java ? Je sais plus... En C(++), c'est clair que non.)
Si tu veux faire plus compliquer (du genre rajouter une classe fille de piece) là va falloir mettre en jeu des mécanisme plus complexes (RTTI, etc...).
Ca dépend de ce que tu fais.
Si c'est juste un programme d'échec, que tu veux fonctionnel et rapide à faire, le plus simple c'est les "if".
Si tu fais un exo de Génie Logiciel, opte pour la deuxième solution (mes connaissance s'arrête là ou commence le Java, sur ce point, par contre...)
Pour ton soucis, un bête "if then else", voire un switch (ça marche avec les string, en Java ? Je sais plus... En C(++), c'est clair que non.)
Si tu veux faire plus compliquer (du genre rajouter une classe fille de piece) là va falloir mettre en jeu des mécanisme plus complexes (RTTI, etc...).
Ca dépend de ce que tu fais.
Si c'est juste un programme d'échec, que tu veux fonctionnel et rapide à faire, le plus simple c'est les "if".
Si tu fais un exo de Génie Logiciel, opte pour la deuxième solution (mes connaissance s'arrête là ou commence le Java, sur ce point, par contre...)
Exactement, c'est un jeu d'échec.
Mes constructeurs des types de pièce ont les même paramètres.
Je pourrais pas passer en paramètre de type d'objet? De cette façon je pourrais créer un objet a partir du type passer en paramètre.
J'ai pensé aux if-then-else et switch, mais je me demandais s'il n'y avait pas plus court. C'est pour cela que je cherche a passer un un type d'objet en paramètre qui serais utilisé imédiatement après mon "new"
Merci
Mes constructeurs des types de pièce ont les même paramètres.
Je pourrais pas passer en paramètre de type d'objet? De cette façon je pourrais créer un objet a partir du type passer en paramètre.
J'ai pensé aux if-then-else et switch, mais je me demandais s'il n'y avait pas plus court. C'est pour cela que je cherche a passer un un type d'objet en paramètre qui serais utilisé imédiatement après mon "new"
Merci
choubaka
Messages postés
39420
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
19 février 2025
2 104
1 avril 2005 à 10:35
1 avril 2005 à 10:35
salut
utilise le design pattern "Method Factory"
Chouba,
Pochard d'assaut ..
utilise le design pattern "Method Factory"
public interface PionFactory { public Piece getPiece( String piece, String couleur ); } public class ConcretePionFactory implements PionFactory { public Piece getPiece( String piece, String couleur ) { if ( "Cavalier".equals( piece ) ) return new Cavalier(couleur); else if ( "Dame".equals( piece ) ) return new Dame(couleur); else return new Pion(couleur); } }--
Chouba,
Pochard d'assaut ..
choubaka
Messages postés
39420
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
19 février 2025
2 104
1 avril 2005 à 11:02
1 avril 2005 à 11:02
autre solution possible est de créer les pièces du jeu à la volée en les plaçant dans une structure de données. C'est à dire créer une classe spécialisée qui va créer les différentes pièces en une fois.
public class PieceFactory{ private Vector piecesNoirs; private Vector piecesBlanches; public PièceFactory(){ piecesNoirs = new Vector(); piecesblanches = new Vector(); } public Vector getPiecesBlanches(){ // là tu crées tes objets et tu les inséres dans le vecteur return piecesBlanches ; } public Vector getPiecesNoirs(){ // là tu crées tes objets et tu les inséres dans le vecteur return piecesNoirs ; } }
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Merci
Je dois faire quelques lectures pour comprendre la première suggestion de choubaka sur le mot clé "interface" je maitrise pas. J'ai déjà vu mais c'est loin.
Ce que je veux faire c'est dans le cas d'une promotion d'un pion, lorsqu'on joue au échec, le pion peux se transformer en n'importe quel pièce, dont la méthode que je veux construire.
Mon damier est crée dans un tableau à deux dimensions, j'ai ajouter sur certaine case mes pièces. Donc mes pièces ne sont dans aucune structure, elle sont dans un objet appelé "Case"
Je crois donc que la première suggestion de choubaka doit être étudier de près.
Je dois créer une nouvelle Classe:
Puis un autre Classe (je pense):
Cire
Je dois faire quelques lectures pour comprendre la première suggestion de choubaka sur le mot clé "interface" je maitrise pas. J'ai déjà vu mais c'est loin.
Ce que je veux faire c'est dans le cas d'une promotion d'un pion, lorsqu'on joue au échec, le pion peux se transformer en n'importe quel pièce, dont la méthode que je veux construire.
Mon damier est crée dans un tableau à deux dimensions, j'ai ajouter sur certaine case mes pièces. Donc mes pièces ne sont dans aucune structure, elle sont dans un objet appelé "Case"
Je crois donc que la première suggestion de choubaka doit être étudier de près.
Je dois créer une nouvelle Classe:
public interface PionFactory { // avec cette entête de méthode public Piece getPiece( String piece, String couleur ); }
Puis un autre Classe (je pense):
public class ConcretePionFactory implements PionFactory { // avec cette méthode public Piece getPiece( String piece, String couleur ) { if ( "Cavalier".equals( piece ) ) return new Cavalier(couleur); else if ( "Dame".equals( piece ) ) return new Dame(couleur); else return new Pion(couleur); } }
Cire
choubaka
Messages postés
39420
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
19 février 2025
2 104
4 avril 2005 à 07:50
4 avril 2005 à 07:50
salut
tu peux jouer alors sur l'état d'un pion et le faire changer. Chaque état de ton pion sait comment faire agir ton pion. trnasfert de résponsabilité.
tu crées une interface afin de garder la même signature des méthode et ce pour tous les états.
Chaque pion possède son état actuel et est capable de le modifier.
Il suffit de créer autant d'objet ConcreteStateOfPions (implémentant l'interface) que nécessaire.
si on travaille comme ça, les pions sont des pions génériques, la seule chose qui les différencie c'est l'état actuel dans lequel ils se trouvent.
par exemple, l'état Roi
j'espère que c'est compréhensible, c'est plus ou moins l'application du State Pattern
tu peux jouer alors sur l'état d'un pion et le faire changer. Chaque état de ton pion sait comment faire agir ton pion. trnasfert de résponsabilité.
tu crées une interface afin de garder la même signature des méthode et ce pour tous les états.
Chaque pion possède son état actuel et est capable de le modifier.
public interface StateOfPion { public void movePion (); // un exemple de méthode agissant sur le comportement d'un pion possédant l'état. public StateOfPion getState(); // retourne l'état actuel public void promoveState(); // chaque état doit savoir comment être promu }
Il suffit de créer autant d'objet ConcreteStateOfPions (implémentant l'interface) que nécessaire.
si on travaille comme ça, les pions sont des pions génériques, la seule chose qui les différencie c'est l'état actuel dans lequel ils se trouvent.
par exemple, l'état Roi
public class ConcreteStateOfKing implements StateOfPion { // il suffit d'implémenter les méthodes de l'interface } // Par défaut, les pions sont dans l'état d'un simple pion, il suffit de faire modifier l'état en fonction de l'évolution du jeu. Par exemple dans le cas du démarrage du jeu, la case sur laquelle se trouve le pion va déterminer sont état initial. // Etat par défaut (générique) public class ConcreteGenericStateOfPion implements StateOfPion{ } public class GenericPion{ private StateOfPion currentState; public GenericPion(StateOfPion currentState){ this.currentState = currentstate; } public GenericPion(){ this.currentState = new GenericStateOfPion (); } public StateOfPion getCurrentState (){ return currentState; } } // Il est important que ce soit l'état du pion qui détermine son comportement.
j'espère que c'est compréhensible, c'est plus ou moins l'application du State Pattern
Bon je comprend de mieux en mieux.
Mais dit moi, es-ce équivalent à mon code ci-bas?
Puis exemple de la définition du roi
ou celui du fou
Chacune des pièces est crée en redéfinisant la méthode estValide qui est abstract dans piece.
La seule déférence a mes yeux c'est que dans un métode de type interface toute les méthodes sont abstraite, moi je n'ai qu'une.
De la foncon que c'est implémenté il y a t'il une différence? Es-ce que changer un pion en une autre pièce représente une difficulté dans mon implémentation?
Cire
Mais dit moi, es-ce équivalent à mon code ci-bas?
public abstract class Piece { private String nom; private String couleur; public Piece (String nom, String couleur) { setNom(nom); setCouleur ( couleur ); } public String getNom () { return nom; } public void setNom (String nom) { this.nom = nom; } public String getCouleur () { return couleur; } public void setCouleur ( String couleur ) { if (( couleur == "noir" ) || ( couleur == "blanc" )) this.couleur = couleur; } public abstract boolean estValide (Position depart, Position arrivee); }
Puis exemple de la définition du roi
public class Roi extends Piece { public Roi(String nom, String couleur) { super(nom, couleur); } public boolean estValide (Position depart, Position arrivee) { // Méthode norme calcul la différence en deux nombres if(norme (depart, arrivee) <= 2) return true; else return false; } }
ou celui du fou
public class Fou extends Piece { public Fou(String nom, String couleur) { super(nom, couleur); } public boolean estValide (Position depart, Position arrivee) { if(Math.abs(depart.getLigne() - arrivee.getLigne()) == Math.abs(depart.getColonne() - arrivee.getColonne())) return true; else return false; } }
Chacune des pièces est crée en redéfinisant la méthode estValide qui est abstract dans piece.
La seule déférence a mes yeux c'est que dans un métode de type interface toute les méthodes sont abstraite, moi je n'ai qu'une.
De la foncon que c'est implémenté il y a t'il une différence? Es-ce que changer un pion en une autre pièce représente une difficulté dans mon implémentation?
Cire
choubaka
Messages postés
39420
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
19 février 2025
2 104
6 avril 2005 à 07:51
6 avril 2005 à 07:51
Salut
le problème c'est que au départ, un objet "Fou" est instancié comme objet "Fou", il ne peut donc pas être changé en un autre type de pièce sans être "détruit". C'est pour celà que je te proposais de travailler avec des pièces génériques où seul le rôle (l'état) dans le jeu pouvait changer et faire réagir les pièces avec les spècificité dues à ce rôle. Donc dans ton code, tu risques d'avoir des problèmes de promotion
le problème c'est que au départ, un objet "Fou" est instancié comme objet "Fou", il ne peut donc pas être changé en un autre type de pièce sans être "détruit". C'est pour celà que je te proposais de travailler avec des pièces génériques où seul le rôle (l'état) dans le jeu pouvait changer et faire réagir les pièces avec les spècificité dues à ce rôle. Donc dans ton code, tu risques d'avoir des problèmes de promotion