Bonjour, 

Je dois faire un echiquier en C#. 

J'ai déjà l'IHM et différentes classe comme Case, Piece, Partie et echiquier. 

D'après mes consignes, la classe Case est liée à la classe Pièce. 

J'ai une methode Link qui lie l'ancienne pièce à la nouvelle pièce passé en paramètre et la méthode unlink qui fait l'inverse. 

Le souci est que j'ai un problème de référence, des cases et des pièces au moment où je veux placer les pieces dans la classe Joueur sur l'IHM

Pouvez vous m'aider ? 

la classe Case

        public Piece piece;
        Case oldCase;
        Partie partie;
        // InfoPiece infoPiece; 
        private int x, y;
        public int X
        {
            get { return x; }
            set { x = value; }
        }

        public int Y
        {
            get { return y; }
            set { y = value; }
        }
        // associations
        public Case(Piece piece)
        {
            this.piece = piece;

        }

        // methodes
        public void Link(Piece newPiece)
        {
            oldCase = piece.position[x,y]; 
            // 1. Deconnecter newPiece de l'ancienne case
            oldCase.unLink(newPiece);
            // 2. Connecter newPiece à cette case
           // Case newCase = new Case(newPiece);
            this.Link(newPiece);
            partie.vue.ActualiserCase(x,y, newPiece.info); 
            
        }
        public void unLink(Piece newPiece)
        {
            newPiece = null; 
            partie.vue.ActualiserCase(x, y, newPiece.info); 
        }

la Classe Piece : 

        // attributs
        public InfoPiece info;
        
        // associations
        public Joueur joueur;
        public Case caseCourante;
        public Case[,] position;
         

        // methodes
        public Piece(Joueur joueur, TypePiece type)
        {
			this.joueur = joueur;
            info = InfoPiece.GetInfo(joueur.couleur, type);
            caseCourante = new Case(this);
            position = new Case[caseCourante.X, caseCourante.Y]; 
        }

        public abstract bool Deplacer(Case destination);
    }

la classe Echiquier : 

        int x, y; 
        public Partie partie;
        public Case[,] cases; 
        public Echiquier (Partie partie)
        {
            this.partie = partie;
            x = 8;
            y = 8;
            cases = new Case[x, y]; 
        }

La methode placerPieces de la classe Joueur où j'ai le bug

        public void PlacerPieces(Echiquier echiquier)
        {
            if( couleur == CouleurCamp.Noire )
            {
                echiquier.cases[3, 0].Link(pieces[0]);
            }
            else
            {
                echiquier.cases[3, 7].Link(pieces[0] );
            }
        }

la console de debug : 

merci !!! 

Revoyez votre conception, c'est atrocement complexe pour rien votre machin.

Genre, avez-vous vraiment besoin d'une classe "Case" ???

C'est quoi sa fonction ???

Qui a rempli "cases" de "echiquier" avec autre chose que null ?

Faites simple.

bacelar a écrit:

Revoyez votre conception, c'est atrocement complexe pour rien votre machin.

Genre, avez-vous vraiment besoin d'une classe "Case" ???

C'est quoi sa fonction ???

Qui a rempli "cases" de "echiquier" avec autre chose que null ?

Faites simple.

je suis les directives de mon prof ... 

>je suis les directives de mon prof ...

Vous avez peut-être mal compris ses directives.

-
Edité par bacelar 8 novembre 2017 à 10:59:38

public Echiquier (Partie partie)
{
    this.partie = partie;
    x = 8;
    y = 8;
    cases = new Case[x, y]; //il faut le remplir
}

Dans ta classe Echiquier tu définis un tableau de 8 lignes et 8 colonnes mais à aucun moment tu ne le remplis avec des objets de type Case donc chaque élément de ton tableau reste à sa valeur par défaut : null.

Sinon pour ton problème de conception évoqué par bacelar tu devrais détailler tes consignes pour y voir plus clair

Stit84 a écrit:

public Echiquier (Partie partie)
{
    this.partie = partie;
    x = 8;
    y = 8;
    cases = new Case[x, y]; //il faut le remplir
}

Dans ta classe Echiquier tu définis un tableau de 8 lignes et 8 colonnes mais à aucun moment tu ne le remplis avec des objets de type Case donc chaque élément de ton tableau reste à sa valeur par défaut : null.

Sinon pour ton problème de conception évoqué par bacelar tu devrais détailler tes consignes pour y voir plus clair

Je te remercie mais je pensais que je le remplissais dans la fonction placerPiece non ?

Si tu as une classe case, faute remplir de case, si tu as une classe pièce tu rempli les zones correspondantes de pièces.

Si tu as les 2 comme dans ton cas, tu remplis de case et ensuite tu associe les cases avec les bonnes pièces. Cela semble tout de suite plus compliqué donc on en revient à ta structure de code Mais ça reste faisable quand même

Jean-BaptisteTchepitchian a écrit:

Si tu as une classe case, faute remplir de case, si tu as une classe pièce tu rempli les zones correspondantes de pièces.

Si tu as les 2 comme dans ton cas, tu remplis de case et ensuite tu associe les cases avec les bonnes pièces. Cela semble tout de suite plus compliqué donc on en revient à ta structure de code Mais ça reste faisable quand même

ok je vois, mais je vois pas comment les remplir vu que c est des images d'IHM

Hello,

J'ai pas suivi toute la tambouille mais pour ton problème de départ déjà ce serait chouette de nous donner le message d'erreur.

Ensuite, le problème vient bien de là : 

if( couleur == CouleurCamp.Noire )
{
    echiquier.cases[3, 0].Link(pieces[0]);
}
else
{
    echiquier.cases[3, 7].Link(pieces[0] );
}

Tu ne peux pas faire ça car echiquier.cases[x,y] va te renvoyer null, et ce quelque soit la valeur de x et y. Tu initialises ton tableau dans le constructeur de Echiquier avec des valeurs null. Par défaut, un tableau va être rempli avec la valeur par défaut du type qu'il contient et comme ici c'est un objet la valeur par défaut est null.
Ça ne pose pas de problème en soit mais tu choisi de récupérer cet objet et d'appeler sa méthode Link(...). Or, tu ne peux pas appeler la méthode Link(...) d'un objet null, ça n'a pas de sens et le programme te le fait savoir avec une erreur.

Il faut ajouter un nouvel objet Case pour chaque index du tableau, avec null en tant que pièce de départ. Sinon tu vas te retrouver avec ce problème partout.

Je rejoins mes camarades pour dire que cette conception est atrocement compliquée pour rien. Selon moi, la classe Case n'a pas lieu d'être, un échiquier c'est juste un tableau de Piece en coordonnées X,Y. La logique de déplacement est contenue dans la classe Piece et la seule info de la classe Case (si peu utile qu'elle soit) peut être déduite grâce aux coordonnées ou si une Piece est déjà à cet index du tableau ou non.
Après, c'est plus une remarque qu'un jugement, ça ne serait pas le premier prof de l'univers à demander des trucs bizarres en guise d'exercice.

bacelar a écrit:

>je suis les directives de mon prof ...

Vous avez peut-être mal compris ses directives.

-
Edité par bacelar 8 novembre 2017 à 10:59:38

non je n'ai pas mal compris car il nous a donné le projet déjà structuré .. juste à remplir les méthode et décommenter les test... 

Pyrobolser a écrit:

Hello,

J'ai pas suivi toute la tambouille mais pour ton problème de départ déjà ce serait chouette de nous donner le message d'erreur.

Ensuite, le problème vient bien de là : 

if( couleur == CouleurCamp.Noire )
{
    echiquier.cases[3, 0].Link(pieces[0]);
}
else
{
    echiquier.cases[3, 7].Link(pieces[0] );
}

Tu ne peux pas faire ça car echiquier.cases[x,y] va te renvoyer null, et ce quelque soit la valeur de x et y. Tu initialises ton tableau dans le constructeur de Echiquier avec des valeurs null. Par défaut, un tableau va être rempli avec la valeur par défaut du type qu'il contient et comme ici c'est un objet la valeur par défaut est null.
Ça ne pose pas de problème en soit mais tu choisi de récupérer cet objet et d'appeler sa méthode Link(...). Or, tu ne peux pas appeler la méthode Link(...) d'un objet null, ça n'a pas de sens et le programme te le fait savoir avec une erreur.

Il faut ajouter un nouvel objet Case pour chaque index du tableau, avec null en tant que pièce de départ. Sinon tu vas te retrouver avec ce problème partout.

Je rejoins mes camarades pour dire que cette conception est atrocement compliquée pour rien. Selon moi, la classe Case n'a pas lieu d'être, un échiquier c'est juste un tableau de Piece en coordonnées X,Y. La logique de déplacement est contenue dans la classe Piece et la seule info de la classe Case (si peu utile qu'elle soit) peut être déduite grâce aux coordonnées ou si une Piece est déjà à cet index du tableau ou non.
Après, c'est plus une remarque qu'un jugement, ça ne serait pas le premier prof de l'univers à demander des trucs bizarres en guise d'exercice.

je comprends mieux merci... et je suis d'accord que sa conception est compliquée.. il nous a fait pareil pour un simple démineur et un tetris... mais je dois le faire avec sa structure malheureusement. 

Oublie pas de passer ton sujet en résolu si tout est rentré dans l'ordre

j'ai essayé de remplir le tableau de case mais il est toujours vide.. je crois que je suis en train de m'embrouiller.. 

    public class Echiquier
    {
        public int x, y; 
        public Partie partie;
        public Case[,] cases;
        public Case c; 
        //Piece piece; 

        public Echiquier (Partie partie)
        {
            this.partie = partie;
            x = 8;
            y = 8;
            for (int i = 0; i < x; i++)
            {
                for (int j = 0;  j < y;  j++)
                {
                    cases[i, j] = new Case(c.piece);
                }
            }
            
        }
    }

Naaahh...

Pourquoi il y aurait une "Case c" dans un Echiquier, ça n'a pas de sens, je sais bien que tu cherches à résoudre ton truc mais il faut pas faire n'importe quoi non plus

En gros, ajoute des cases avec null à la place de c.piece. ça ajoutera des "cases" vides à ton Echiquier.

Pyrobolser a écrit:

Naaahh...

Pourquoi il y aurait une "Case c" dans un Echiquier, ça n'a pas de sens, je sais bien que tu cherches à résoudre ton truc mais il faut pas faire n'importe quoi non plus

En gros, ajoute des cases avec null à la place de c.piece. ça ajoutera des "cases" vides à ton Echiquier.

je voulais mettre les pieces de ma classe case... si je mets nulle ca me met tjrs l erreur System.NullReferenceException

Donc ça veut dire qu'on ne peut pas créer de cases vides ou qu'on ne peut pas déplacer une pièce autre part que sur une case occupée...

Nan je suis désolé mais là y'a vraiment un truc bizarre, j'aurai essayé !

Pyrobolser a écrit:

Donc ça veut dire qu'on ne peut pas créer de cases vides ou qu'on ne peut pas déplacer une pièce autre part que sur une case occupée...

Nan je suis désolé mais là y'a vraiment un truc bizarre, j'aurai essayé !

merci quand meme ...

Pyrobolser a écrit:

Donc ça veut dire qu'on ne peut pas créer de cases vides ou qu'on ne peut pas déplacer une pièce autre part que sur une case occupée...

Nan je suis désolé mais là y'a vraiment un truc bizarre, j'aurai essayé !

j'ai changé le code mais j'arrive toujours pas à regler les problème de null reference 

    public class Case
    {

        // attributs
        public CouleurCamp couleur; 
        public int x, y;

        Partie partie;
        public Piece piece;
     //   public List<Case> cases = new List<Case>(); 
        Case oldCase;
        // associations
        public Case(Partie partie, Piece piece, CouleurCamp couleur, int x, int y)
        {
            this.couleur = couleur;
            this.x = x;
            this.y = y;
            this.partie = partie;
            this.piece = piece;
            
        }
        public Case cases  
            {
                get; set; 
            }

        // methodes
        public void Link(Piece newPiece)
        {
            //casesTab[x, y] = newPiece.position; 
            oldCase = newPiece.position;
            // 1. Deconnecter newPiece de l'ancienne case
            oldCase.UnLink(newPiece);
            // 2. Connecter newPiece à cette case
            this.cases = newPiece.position; 
            partie.vue.ActualiserCase(x, y, newPiece.info);
        }
        public void UnLink(Piece newPiece)
        {
            newPiece = null;
            partie.vue.ActualiserCase(x, y, null);


        }

il y a un soucis dans ma classe Case, oldCase retourne null 

        public Piece(Joueur joueur, TypePiece type)
        {
			this.joueur = joueur;
            info = InfoPiece.GetInfo(joueur.couleur, type);
            position = new Case(partie, this, couleur, 0, 0);
        }

la classe echiqier 

    public class Echiquier
    {
        //attributs 
        int raw, col;
        Partie partie;
        public Case[,] cases; 
        public Echiquier(Partie partie)
        {
            this.partie = partie;
            raw = 8;
            col = 8;
            cases = new Case[raw, col];
            for (int i = 0; i < raw; i++)
            {
                for (int j = 0; j < col; j++)
                {
                    cases[i, j] = new Case(partie, null, 0, i, j); 
                }
            }
        }

    }
}

dans les directives j'ai : 

- une classe << Echiquier >> reliée à la classe << Case >> par une composition de un à plusieurs

- une classe << Piece >> reliés à la classe << Case >> par une association zéro ou un.

-
Edité par deborahLevy 13 novembre 2017 à 17:40:49

C'est toujours aussi abscons !!!

C'est quoi cette propriété cases dans la classe Case ??? (Inception inside)

Le champ "oldClass" n'est jamais explicitement initialisé, et comme il ne sert très semblablement à rien, virez le.

newPiece.position.UnLink(newPiece);

La ligne 40 sert à quoi ??? WTF

>- une classe << Echiquier >> reliée à la classe << Case >> par une composition de un à plusieurs

OK, je ne vois rien qui oblige à utiliser un tableau à 2 dimensions, très loin de là.

Une simple liste de cases respecterait parfaitement cette directive.

>- une classe << Piece >> reliés à la classe << Case >> par une association zéro ou un.

Formulation ambiguë, c'est la pièce qui référence la case ou la case qui référence la pièce, ou les 2 ???

Et rien dans votre code ne permet de voir facilement si vous avez respectez cette directive.

Qu'est qui fait que les cases construites dans le constructeur de pièces prennent la place des cases "vide" de l’échiquier ???

j ai reglé mon problème 

        public void Link(Piece newPiece)
        {
            cases = new Case(partie, piece, couleur, 0, 0);
            oldCase = new Case(partie, piece, couleur, 0, 0);
            if (oldCase.piece != null)
            {
                cases.piece = newPiece;
                newPiece.position = cases;
                oldCase.piece = null;
                oldCase.UnLink(newPiece);
            }

                partie.vue.ActualiserCase(x, y, newPiece.info);

        }
        public void UnLink(Piece newPiece)
        {
            newPiece = null;
            partie.vue.ActualiserCase(x, y, null);
        }

merci à tous !

La ligne 18 est toujours aussi WTF.

Et ce n'est pas à votre couche métier de modifier/appeler votre couche d'IHM (ligne 13 et 09).

Ligne 5, test complètement con.

Beaucoup trop de champs avec des informations redondantes dans la classe Case, etc...

Vous vous noyez dans un verre d'eau.

bacelar a écrit:

La ligne 18 est toujours aussi WTF.

Et ce n'est pas à votre couche métier de modifier/appeler votre couche d'IHM (ligne 13 et 09).

Ligne 5, test complètement con.

Beaucoup trop de champs avec des informations redondantes dans la classe Case, etc...

Vous vous noyez dans un verre d'eau.

encore une fois, je complete les fonctions du projet de mon prof, j ai des parties de code a décommenter, je dois faire en sorte que ca run donc je fais en fonction.

Vos remarques ne sont pas constructifs y a rien derrière. Je cherches pas ce genre de critiques dans un Forum 

Oublie pas de passer le sujet en résolu

Donnez nous le code du prof., SVP.

bacelar a écrit:

Donnez nous le code du prof., SVP.

ca serait beaucoup trop long.. et j ai mis le sujet en resolu trop vite.. les pieces sont bien affichés dans le board mais j ai toujours un problème de null reférence. Dans ma fonction Link, la case position reste de coordonnée (0, 0), la pièce est null aussi et le lien entre la nouvelle case et l'ancienne se fait pas ca me retourne null.

>ca serait beaucoup trop long.

Utilisez GitHub.

Votre code est horriblement complexe et vous ne nous donnez pas tout le code pertinent.

Si vous n'êtes pas capable d'expliquer CLAIREMENT la fonction Link et de la fonction UnLink, c'est qu'il y a un problème dans votre analyse.

En voyant le code, je ne vois que des effets de bords avec tout ce que cela entraine comme problème de maintenance.

Utilisez le débogueur pour voir où le comportement change par rapport à vos attente.

Mais s'en tout le code, dans GitHub, c'est peine perdu.

bacelar a écrit:

>ca serait beaucoup trop long.

Utilisez GitHub.

Votre code est horriblement complexe et vous ne nous donnez pas tout le code pertinent.

Si vous n'êtes pas capable d'expliquer CLAIREMENT la fonction Link et de la fonction UnLink, c'est qu'il y a un problème dans votre analyse.

En voyant le code, je ne vois que des effets de bords avec tout ce que cela entraine comme problème de maintenance.

Utilisez le débogueur pour voir où le comportement change par rapport à vos attente.

Mais s'en tout le code, dans GitHub, c'est peine perdu.

voila mon lien git : https://github.com/debydebo/TP3_Echecs.git

La méthode Unlink annule la référence sur l’objet Piece et soulève un événement ActualiserCase pour effacer la case correspondante dans l’IHM.

La méthode Link commence par invoquer Unlink sur la case où la pièce d’entrée se trouve, relie celle-ci avec la case courante et enfin soulève un événement ActualiserCase pour mettre à jour le contenu de la case correspondante dans l’interface utilisateur. 

Merci pour le Git.

Pouvez-vous y mettre aussi le squelette fourni par le professeur ?

Votre code est complexe et une vue d'ensemble ne semble pas simplifier notre compréhension.

Le code est un mélange de code extrêmement structuré (usage d'interface, de couche logicielle, etc..) et d'énormes erreurs de conception (utilisation des namespace complètement aux fraises, noms de méthode peu clairs, levelisation de l'architecture impossible, etc...).

Vous avez des cases dans l'échiquier et dans les pièces, c'est un endroit de trop.

Réfléchissez un peu avant de coder. Où comptez vous implémenter les règles des échecs ?

Pas dans les pièces car il vous faut une vue d'ensemble de l'échiquier pour appliquer les règles.

Donc, les pièces n'ont pas besoin de toutes ces infos et donc encore moins d'une "case".

J'ai pas été assez clair dans ma question sur le rôle des fonctions "Link" et "Unlink", ma question c'était "à quoi elles servent" pas "ce qu'elle font".

Avec l'ensemble du code, leur rôle devient plus clair, mais je trouve que c'est une manière extrêmement lourde pour faire du databinding.

>Dans ma fonction Link, la case position reste de coordonnée (0, 0), la pièce est null ...

Normal, vous utilisez des objets "Piece" dont le constructeur n'initialise pas tous ses champs, vous avez des objets qui ne sont pas complètement opérationnel en sortie de constructeur.

Donc, quand vous vous en servez, ça pète.

Si vous ne mettez pas de case dans "Pièce", vous ne ferez plus cette erreur, et la constructeur d'une pièce pourra peut-être enfin construire un objet complètement opérationnel.

bacelar a écrit:

Merci pour le Git.

Pouvez-vous y mettre aussi le squelette fourni par le professeur ?

Votre code est complexe et une vue d'ensemble ne semble pas simplifier notre compréhension.

Le code est un mélange de code extrêmement structuré (usage d'interface, de couche logicielle, etc..) et d'énormes erreurs de conception (utilisation des namespace complètement aux fraises, noms de méthode peu clairs, levelisation de l'architecture impossible, etc...).

Vous avez des cases dans l'échiquier et dans les pièces, c'est un endroit de trop.

Réfléchissez un peu avant de coder. Où comptez vous implémenter les règles des échecs ?

Pas dans les pièces car il vous faut une vue d'ensemble de l'échiquier pour appliquer les règles.

Donc, les pièces n'ont pas besoin de toutes ces infos et donc encore moins d'une "case".

J'ai pas été assez clair dans ma question sur le rôle des fonctions "Link" et "Unlink", ma question c'était "à quoi elles servent" pas "ce qu'elle font".

Avec l'ensemble du code, leur rôle devient plus clair, mais je trouve que c'est une manière extrêmement lourde pour faire du databinding.

>Dans ma fonction Link, la case position reste de coordonnée (0, 0), la pièce est null ...

Normal, vous utilisez des objets "Piece" dont le constructeur n'initialise pas tous ses champs, vous avez des objets qui ne sont pas complètement opérationnel en sortie de constructeur.

Donc, quand vous vous en servez, ça pète.

Si vous ne mettez pas de case dans "Pièce", vous ne ferez plus cette erreur, et la constructeur d'une pièce pourra peut-être enfin construire un objet complètement opérationnel.

Pour les cases dans l echiquier et dans les pieces, c'est parce que selon mon prof la classe echiquier est liée par la classe Case  par une composition de un à plusieurs et la classe Piece est liée à la classe Case par une association zéro ou un.

Pour les règles, je comptes les implémenter dans chaque classe Dame, Pion, Roi qui héritent de la classe Piece.. je les implémente donc dans la fonction Deplacer. 

Link et Unlink sont appelé lors des déplacements des pièces, c'est à dire que lorsque l'on déplace une pièce, la case de départ  est alors vide pour que la case de destination soit lié à la piece déplacée.

Dans le code donné par le prof il y avait dans la classe Piece, Case Position mais qui n'etait pas instancié. Comme la case doit contenir une ou zero piece, je pensais que pour pouvoir liée les 2 classe, il fallait les ajouter dans le constructeur.  

-
Edité par deborahLevy 15 novembre 2017 à 15:39:37

Ok, j'ai jeté un coup d’œil rapide au code que vous m'avez envoyé par e-mail.

Votre prof n'est clairement pas partisan de la simplicité, à première vue.

Il doit avoir été un peu trop nourri à la POO (et de la toute moisie) et pas assez avec KISS (Keep It Simple and Stupid).

Mais on va essayer de garder les choses simples sans toucher à son squelette (d'ornithorynque) de code.

Franchement, la case dans la pièce, c'est n'importenawak.

(Votre prof., c'est pas un troll qui se marre à vous voir vous débattre dans l'usine à gaz qu'il à conçu pour vous faire tourner en bourrique ???)

Une chose qui complexifie horriblement ce code, c'est le fait que des informations sont redondantes dans tous les coins, et que si l'un de ces coins ne propage pas les modifications aux autres, c'est la merde.

On va donc essayer de réduire ce capharnaüm.

Celui qui pose problème actuellement, c'est ces cases qui se baladent partout.

On va centrer la gestion des cases dans l'échiquier. C'est le seul à en créer et si du code d'une autre classe en n'a besoin, c'est l'échiquier qui le fourni, personne d'autre.

Sans changer les signatures des méthodes de son usine à shadoks, faut ruser.

Comme votre professeur code en français, comme un codeur "béret-baguette" des années 50, il a bien été dans la m.... pour avoir un champ "case" qui correspondrait à son rôle supposé, de case de la pièce. Position, ce n'est pas une case, bordel. C'est une paire {x,y} de l'espace 2D de l'échiquier. Mais "case", c'est un mot réservé du C#, il est bien de le caca, mais il doit pas connaitre le @-quotation ( https://stackoverflow.com/questions/254669/what-does-placing-a-in-front-of-a-c-sharp-variable-name-do )

Votre professeur est un guignol !!!!

Quand on dit de coder en anglais, c'est pas juste pour se faire mousser.

Bon, passons.

Vous allez initialiser le champ "position" des pièces à null car on va prendre la sémantique suivante : soit votre pièce n'est pas encore dans l'échiquier ou elle ni est plus et le champ "position" (putain, je me ferais jamais à ce nom à la con) est à null ; soit elle est sur l'échiquier et le champ "position" ( re-putain, c'est une case ) devra contenir la case sur l'échiquier.

Le fait que le constructeur d'une pièce laisse "position" (WTF ) à null entérine le fait qu'une pièce qui vient d'être créée n'est pas encore sur l'échiquier.

Du coup, la méthode "Deplacer" permet de mettre à jour le champ "position" pour qu'il corresponde à la sémantique du champ "position" (FUCK ) qu'on vient de spécifier. Donc on va dire que "Deplacer(null)" correspondra à la sortie de la pièce de l'échiquier.

C'est tellement trivial, que je comprends pas pourquoi il vous a collé un abstract dans la signature de "Deplacer.

Vous êtes bon pour faire un copier-coller merdique dans chaque classe dérivée de "Piece" avec un code proche de :

//*
   si le paramètre destination est null,
     c'est une mise hors de l'échiquier de la pièce
*//
public override bool Deplacer(Case destination)
{
    /* Ici ajoutez le code de vérification du 
       déplacement spécifique au type de la pièce
       mais qui n'a rien à foutre ici dans une conception
       simple et soignée (BORDEL!!!)
    */
    position = destination;
    return true;
}

Vous ne devriez donc plus avoir aucun "new Case" ailleurs que dans le constructeur de la classe Echiquier.

Une astuce pour faire le ménage dans le code, c'est de changer temporairement la signature du constructeur de Case, en prenant un Echiquier en paramètre par exemple. Le compilateur vous indiquera tous les appels explicites, mais aussi implicites, au constructeur de Case que vous ne devrez plus faire (en attendant d'utiliser correctement les scopes des déclarations, ce que votre professeur n'en a cure, quel imb... ).

Le code de la classe "Case" deviendrait simple :

namespace TP2_Echecs.Echecs
{
    public class Case
    {
        // attributs
        public event EventHandler Changed;

        // associations
        

        // methodes
        public void Link(Piece newPiece)
        {
            if(newPiece.position!=this)
            {
                Case sourceCase = newPiece.position;
            // 1. Deconnecter newPiece de l'ancienne case
            // 2. Connecter newPiece à cette case
                if(newPiece.Deplacer(this))
                {
                    if(sourceCase != null)
                    {
                        //Mécanisme de déclenchement d'évènement d'une autre instance à vérifier
                        EventHandler handler = sourceCase.Changed;
                        if (handler != null)
                        {
                            handler(sourceCase, EventArgs.Empty);
                        }
                    }
                    EventHandler handler = Changed;
                    if (handler != null)
                    {
                        handler(this, EventArgs.Empty);
                    }
                }
            }
        }
    }
}

Unlink, ça sert à rien, Link fait tout le boulot.

> la classe echiquier est liée par la classe Case  par une composition de un à plusieurs

C'est OK, le tableau de case est toujours dans l'échiquier.

C'est pourri comme structure mais on n'a pas trop le choix quand on voit le code pourri qu'il a foutu en commentaire dans Partie.cs:

// case de départ
            //Case depart = echiquier.cases[x_depart, y_depart];

Il est possible de prendre un autre type qu'un tableau 2D, mais c'est un peu plus compliqué, et quand on vous le manque absolu de conception du squelette de base, pourquoi se faire chier.

>la classe Piece est liée à la classe Case par une association zéro ou un.

Ce que fait très bien un champ "position" () initialisé à null et mis à jour dans la méthode "Deplacer".

>je comptes les implémenter dans chaque classe Dame, Pion, Roi qui héritent de la classe Piece.

Grosse erreur de débutant, mais j'ai fortement l'impression que votre professeur est aussi un grand débutant, malheureusement.

Le constat est simple, pour appliquer les règles des échecs, il faut disposer de toutes les informations de l'échiquier, de toutes les positions de toutes les pièces, roque fait ou pas, etc..., toutes ces choses que vous ne pourrez jamais accéder simplement depuis une simple pièce de l'échiquier.

Vous pouvez toujours faire des circonvolutions pour récupérer aux forceps toutes ces informations mais ça fera des liens de dépendances dans tous les sens.

Si les règles sont dans l'échiquier ou dans la partie, cela serait largement plus simple.

Vous allez galérer. Ne pouvez-vous pas demander à votre professeur de revoir sa conception bancale ???

> la case de départ  est alors vide pour que la case de destination soit lié à la piece déplacée.

???

Rien dans le code donné par le professeur (en commentaire ou non) ne fait ces assertions.

>Dans le code donné par le prof il y avait dans la classe Piece, Case Position mais qui n'etait pas instancié

OK pour moi, comme ça je peux facilement gérer les pièces "hors-jeu".

>Comme la case doit contenir une ou zero piece,

Dans le code donné par le professeur, c'est l'inverse.

>je pensais que pour pouvoir liée les 2 classe,

Plus les classes sont liés plus il est difficile de les utiliser.

Il y a déjà bien assez de lien dans le code fourni par le professeur pour se pendre 1000 fois, pas besoin d'en rajouter.

>il fallait les ajouter dans le constructeur.

On n'a le droit de changer la signature des constructeurs ??? Alors on pourrait faire un truc largement plus carré que cette bouillie infâme qu'est le code initial.

bacelar a écrit:

merci beaucoup pour ce message tres complet, je fais faire les modif. 

et pour le constructeur de Case, c'est juste que la Classe case n'etait pas donnée.. donc je peux faire le constructeur que je veux...

pour les regles, je sais que c'est une mauvaise conception mais il l'avait déjà fait pour Dame et ca planterait tous les test si je change tout.. le pire c'est que cette matière s'appelle "Genie Logiciel" on est censé apprendre comment faire une bonne conception.. et Ca fait le 3e projet que sa conception est juste du n'importe quoi...

Je comprends mieux maintenant pourquoi j'ai galéré à comprendre à quoi sert Case position...

autre question, dans le constructeur de Case, j'ai mis Partie pour ensuite appelé partie.vue et changer l'affichage de l'IHM.. sauf que partie est toujours à Null et je comprends pas pourquoi