JAVA - Constructeur variable???

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...)

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

salut

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 .. 

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 ;
            }
}

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:

 
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

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.

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?

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

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