Bonjour tout le monde,

Je suis en train de faire l'activité du cours « Programmez en orienté objet avec C# » de Monsieur Nicolas Hilaire c'est la suite du cours « Apprenez à développer en C# »

Voici une partie du code que j'ai fait :

 // Cette classe Personnage est en "abstract" car d'après l'énoncé de cette activité, elle devait avoir des méthode abstraite.  
    public abstract class Personnage
    {
        public abstract bool EstVivant
        {
            get;
        }
       
        public abstract void Attaque(Personnage perso);
      
        public abstract void SubitDegats(int degats);

        public int LanceLeDe()
        {
            return De.LanceLeDe();
        }
    }

public class MonstreFacile : Personnage
    {
        private const int degats = 10;
        protected bool estEnVie = true;
        public override bool EstVivant
        {
            get
            {
                return estEnVie;
            }
        }
        public override void Attaque(Personnage perso) // Implémentation obligatoire de la méthode abstraite "Attaque" hérité de la classe Personnage 
        {
            int lanceMonstre = LanceLeDe();
        }
        // Polymorphisme de la méthode "Attaque" ci-dessous et cette méthode a été mise en "virtual" en vue d'une substitution 
        public virtual void Attaque(Joueur joueur)
        {
            int lanceMonstre = LanceLeDe();
            int lanceJoueur = joueur.LanceLeDe();
            if (lanceMonstre > lanceJoueur)
                joueur.SubitDegats(degats);
        }


        // Ci-dessous implémentation obligatoire de la méthode abstraite "SubitDegats" hérité de la classe Personnage 

        public override void SubitDegats(int deg)
        {
            estEnVie = false;
        }
        // Polymorphisme "ad hoc" de la méthode "SubitDegats" ci-dessous
        public void SubitDegats()
        {
            estEnVie = false;
        }
    }

Je tiens à préciser que le remaniement complet du code que j'ai effectué fonctionne.

Cependant, je suis gêné par rapport à la théorie car j'ai pu appliquer deux manifestations du polymorphisme à la fois sur la méthode « public virtual void Attaque(Joueur joueur) ». Apparemment, j'ai à la fois effectué, sur cette méthode « Attaque », un polymorphisme « ad hoc » et une substitution.

Je me questionne car pour faire une substitution, normalement, il faut mettre la fonction qu'on est en train de substituer en « override » or cette méthode est en «virtual » mais j'ai pu quand même la redéfinir ou du moins la compléter.

Donc en C#, est-ce que le Polymorphisme « paramétré » peut aussi servir à redéfinir une méthode?

Je vous pose cette question car j'aimerais être très précis et très exacte dans mes commentaires que je suis en train d'écrire pour cette activité et j'aimerais aussi comprendre très précisément et très exactement toutes les subtilités du Polymorphisme

Je vous remercie pour votre aide par avance.

Je vous souhaite une très bonne journée.

Bien cordialement.

Aclanto

-
Edité par aclanto 31 octobre 2019 à 15:01:32

Salut,

D'après ma compréhension du langage, qui n'est pas non plus parfaite (je laisse le soin aux autres internautes de me corriger, j'en suis sur qu'ils ne louperont pas une telle occasion !)

- Virtual : Permet de rédefinir une méthode, un événement ou une propriété d'une classe mère et autorise cette méthode/évènement/propriété à être redéfinit dans une classe derivée

- Override : Permet de redéfinir une méthode, un événement ou une propriété d'une classe mère. Ne l'autorise pas à être redéfinit dans une classe dérivée

J'espère ne pas me tromper et répondre à ton interrogation

Bon week-end

Juste une erreur dans le post de @earp91.

"override" permet de redéfinir une méthode, etc..., mais n'interdit pas la redéfinition de ceux-ci dans les classes dérivées.

C'est le mot-clé "sealed" qui se charge de cette interdiction :

https://docs.microsoft.com/fr-fr/dotnet/csharp/language-reference/keywords/sealed

Pour ce qui est du post de @aclanto, cet exemple me donne des boutons car c'est le même que celui du cours de C++ d'OC qui est une CATASTROPHE.

Je crains que cet exemple soit du même acabit que le cours de C++ d'OC dans son ensemble, une purge.

Les fonctionnalités intrinsèques du C# permettent de se prendre le mur d'une conception bancale un peu plus tard qu'en C++, ce qui peut permettre de se servir de cet exemple "plus longtemps" et peut-être pour l'ensemble du cours de C# et qu'il n'aborde pas comment "bien faire" de l'objet (concept SOLID (Google est ton ami)).

Enfin, bon, c'est vraiment pas tip-top comme exemple de POO, car dans ce cas de figure on préférera une conception ECS à la conception purement POO. Dans ce cas de figure et qu'on cherche vraiment à faire un RPG (multiple classe, multiple classes, multiples type de bonus, etc...), le conception purement POO explosera très vite avec une multiplication de classes, dans les faits très vite ingérable.

> que j'ai effectué fonctionne

Que tu crois.

Il ne fait absolument pas ce que tu crois.

>un polymorphisme « ad hoc » et une substitution.

Vocabulaire choisi et précis, il s'est amélioré depuis son cours C++, à l'évidence, s'il ne s'est pas planté dans ces explications.

Si vous pouvez faire un résumé de ce que vous avez compris pour voir si le message est correct ET qu'il est bien passé aux apprenants, cela serait fort urbain de votre part.

Vos interrogations montent que vous avez un certain recul sur le cours, et c'est cool.

Je ne sais pas ce qu'il entend par "polymorphisme « ad hoc » et de substitution" car c'est fonction du langage, ça varié dans le temps et leur définitions sont assez floues en réalité.

Je ne vais donc pas me baser sur ces concepts "avancés" mais faire quelque-chose de plus "terre à terre".

Vous confondez "surcharge" et "redéfinition".

La redéfinition, c'est le fait de modifier l'implémentation d'une méthode d'une classe mère dans la classe fille.

La surcharge, c'est définition une NOUVELLE méthode qui porte le même nom qu'une autre mais qui n'a pas la même signature (par signature, on entend le nombre et le type de paramètre). Ces méthodes peuvent aussi bien être dans la classe fille que dans les classes mères de celle-ci.

Donc votre "Attaque(Personnage perso)" dans la classe fille est bien une redéfinition de la méthode de la classe mère (même si elle n'est qu'abstraite dans la classe mère, elle existe, c'est juste le compilateur qui vous engueulera si vous essayez d'instancier cette classe mère ou une classe fille qui n'a pas REDÉFINI cette méthode).

Votre "Attaque(Joueur joueur)" n'est qu'un surcharge de votre redéfinition "Attaque(Personnage perso)" et cela explique pourquoi l'override ne fonctionne pas ici. Ce n'est pas une redéfinition mais une surcharge. Et si je comprends ce que sous-entend "substitution" dans votre cours, vous n'êtes clairement pas dans un cas de "substitution".

Avec votre surcharge, l'utilisateur de votre classe "MonstreFacile" n’appellera pas la même méthode avec le code suivant :

monMonstre.Attaque(ennemi);

si "ennemi" est un joueur ou un personnage.

C'est pas très logique pour l'utilisateur de votre classe s'il veut que le monstre attaque autre chose qu'un joueur (son pet, un autre monstre errant, etc...)

En plus, ça doublonne le code si vous implémentez correctement le code de "Attaque(Personnage perso)".

Donc transférez le code de "Attaque(Joueur joueur)" dans "Attaque(Personnage perso)" et supprimez "Attaque(Joueur joueur)".

c'est la même chose pour "SubitDegats", confusion entre redéfinition et surcharge.

Bonsoir Earp91 et Barcelar,

Je vous remercie beaucoup pour vos réponse.

Earp91, je pense que « virtual » autorise juste cette méthode/événement/propriété à être redéfinit dans une classe dérivée à condition que cette cette méthode/événement/propriété dérivée soit en « override » mais sans permettre de redéfinir une méthode, un événement ou une propriété d'une classe mère.

J'ai fais un petit programme qui donne des exemples de surcharge, de substitution, et même de masquage :

public abstract class Animal
    {
        public abstract void Cri();

    }

    public class Chien : Animal
    {
        // Substitution de la méthode Cri()
        public override void Cri()
        {
            Console.WriteLine("Whouaf ! Je suis un chien.");
        }
        // Surcharge de la méthode Cri(string maitre)
        public void Cri(string maitre)
        {
            Console.WriteLine("Whouaf ! Whouaf! Je suis un petit chien, " + maitre +".");
        }
    }

    public class GrosChien : Chien
    {
        // Masquage de la méthode Cri()
        public new void Cri()
        {
            Console.WriteLine("Je suis un gros chien");
        }
        // Masquage de la méthode Cri(string maitre)
        public new void Cri(string maitre)
        {
            Console.WriteLine("Whououf ! Whououf!! Je suis un gros chien, " + maitre + ".");
        }


 class Program
    {
        static void Main()
        {
            Chien medor = new Chien();
            medor.Cri();
            medor.Cri("Aclanto");

            Console.WriteLine();

            GrosChien patapouf = new GrosChien();
            patapouf.Cri();
            patapouf.Cri("Aclanto");
        }
    }

Hé oui, j'ai des chiens qui parlent !

Trêve de plaisanterie.

Vous voyez Earp91 et Barcelar avec la surcharge j'ai pu ajouter un paramètre à ma méthode puis la redéfinir et le tout, Earp91, sans utiliser « virtual ».

Tu as raison Barcelar, je confondais surcharge et redéfinition.

Ceci dit en plus d'ajouter des paramètres ou de changer leur types, la surcharge comme le montre mon petit programme ci-dessus permet aussi la redéfinition d'une méthode. Donc même si une surcharge est différente d'une redéfinition ; la surcharge de toute façon implique bien souvent une redéfinition. C'est pour cela que j’avais tendance à confondre les deux.

Par contre je ne pense que la surcharge définir une nouvelle méthode qui porte le même nom qu'une autre mais qui n'a pas la même signature. Je pense que la surcharge d'après le cours donne à une méthode une autre signature et peut éventuellement la redéfinir. Voici les liens :

https://openclassrooms.com/fr/courses/2818931-programmez-en-oriente-objet-avec-c/2818941-introduction-a-la-programmation-orientee-objet#/id/r-2827496

https://openclassrooms.com/fr/courses/2818931-programmez-en-oriente-objet-avec-c/2818971-la-poo-et-le-c#/id/r-2828072

Attention, il ne faut pas confondre surcharge et masquage :

https://openclassrooms.com/fr/courses/2818931-programmez-en-oriente-objet-avec-c/2819061-empechez-l-heritage-et-masquez-des-methodes#/id/r-2824929

Petite précision :

Surcharge, Polymorphisme « ad hoc » et Polymorphisme « paramétré » sont trois termes qui désignent la même chose.

Je vais aussi garde la surcharge de SubitDegats() car cela facilite l'écriture du code surtout dans le futur et il me semble que cette écriture plus élégante. Voici cela donne :

    // Cette classe Personnage est en "abstract" car d'après l'énoncé de cette activité, elle devait avoir des méthode abstraite.  
    public abstract class Personnage
    {
        public abstract bool EstVivant
        {
            get;
        }
       
        public abstract void Attaque(Personnage perso);
      
        public abstract void SubitDegats(int degats);

        public int LanceLeDe()
        {
            return De.LanceLeDe();
        }
    }

 public class MonstreFacile : Personnage
    {
        private const int degats = 10;
        protected bool estEnVie = true;
        public override bool EstVivant
        {
            get
            {
                return estEnVie;
            }
        }

        // Implémentation obligatoire et substitution de la méthode abstraite "Attaque" hérité de la classe Personnage 
        public override void Attaque(Personnage perso) 
        {
            int lanceMonstre = LanceLeDe();
            int lanceJoueur = perso.LanceLeDe();
            if (lanceMonstre > lanceJoueur)
                perso.SubitDegats(degats);
        }
        // Surcharge de la méthode "Attaque" ci-dessous et cette méthode a été mise en "virtual" en vue d'une substitution dans la classe dérivé " MonstreDifficile"
        public virtual void Attaque(Joueur joueur)
        {
            int lanceMonstre = LanceLeDe();
            int lanceJoueur = joueur.LanceLeDe();
            if (lanceMonstre > lanceJoueur)
                joueur.SubitDegats(degats);
        }


        // Ci-dessous implémentation obligatoire et substitution de la méthode abstraite "SubitDegats" hérité de la classe Personnage 

        public override void SubitDegats(int deg)
        {
            estEnVie = false;
        }

        // Surcharge de la méthode "SubitDegats" ci-dessous
        public void SubitDegats()
        {
            estEnVie = false;
        }

    }

Je vous remercie encore Barcelar et Earp91 pour vos réponse qui m'ont bien aidé.

Je vous souhaite un très bon week-end.

Bien cordialement.

Aclanto

-
Edité par aclanto 3 novembre 2019 à 17:24:43

>et Barcelar avec la surcharge j'ai pu ajouter un paramètre à ma méthode

Non, vous avez défini une NOUVELLE méthode (surcharge défini de nouvelles méthodes, elle n'"ajoute" pas de paramètres).

>permet aussi la redéfinition d'une méthode.

Non, ça ajoute une méthode, cela ne redéfinit absolument rien.

>la surcharge de toute façon implique bien souvent une redéfinition.

Absolument pas !!!

>Par contre je ne pense que la surcharge définir une nouvelle méthode qui porte le même nom qu'une autre mais qui n'a pas la même signature

C'est la définition de la surcharge, donc arrêtez de "penser" et lisez un "bon" cours de POO.

Les extraits du cours montre que Nicolas Hilaire est toujours aussi "mauvais" en POO, et je ne pense pas être un "puriste".

Il a juste étoffé son vocabulaire mais son mode de raisonnement n'est toujours pas "SOLID".

>deux méthodes peuvent être utile

Peut-être, mais elles sont sources de confusion et cela n'est pas hypothétique.

A moins d'avoir une "vraie" raison, SUPPRIMEZ "Attaque (Joueur joueur)", BORDEL !!!

>si on fait du refactoring

On n'aura qu'une méthode à analyser. Dégagez le code superflu. Moins de code moins de bugs.

>c'est pour faire évoluer le code

Un code simple évolue mieux qu'un code imbitable.

>on pourrait avoir besoin

Avec des si, on coupe des arbres.

>évite de convertir implicitement un objet de type Joueur en objet de type Personnage

Le C# ne supporte pas l'héritage multiple (il n'y a qu'une v_table), il n'y a donc pas de "conversion" entre un objet de la classe dérivée et une de ces classes mères.

>il me semble que c'est mieux sur le principe

La simplicité : "Keep It Simple and Stupid" (KISS).

Supprimez-moi cette cochonnerie, putain.

>Par contre j'ai implémenté « Attaque (Personnage perso) » comme « Attaque (Joueur joueur) »

Du code en double (pour rien), ça vous dérange pas ???

>Je vais aussi garde la surcharge de SubitDegats()

Toujours la même erreur fondamentale, car vous n'avez pas compris l'intérêt de la résolution dynamique de méthode virtuelle. Vraisemblablement parce que le cours que vous suivez n'est pas terrible.

Bonsoir Bacelar,

Je te remercie pour ton dernier message.

Je vais te faire plaisir j'ai bien réfléchir et vais enlever les méthodes que tu m'as dit d'enlever voilà mon nouvel extrait de code :

 // Cette classe Personnage est en "abstract" car d'après l'énoncé de cette activité, elle devait avoir des méthode abstraite.  
        public abstract class Personnage
        {
       
            public abstract bool EstVivant
            {
                get;
            }

            public abstract void Attaque(Personnage perso);

            public abstract void SubitDegats(int degats);

            public int LanceLeDe()
            {
                return De.LanceLeDe();
            }


        }
        // J'ai mis cette classe PersonnageAPointDeVie en "abstract" même si cette classe n'a pas de méthode abstraite car je pense que cela a plus de 
        // sens qu'elle soit en "abstract" étant donné que d'instancier une telle classe ne sert pas à grands choses. il me semble qu'elle a plus vocation à 
        // être dérivé.
        public abstract class PersonnageAPointDeVie : Personnage
        {
        protected int degats = 1;
        // méthode supprimé :
        //public override void Attaque(Personnage perso)
        //{
        //    LanceLeDe();
        //}
        public int PtsDeVies { get; set; }
            public PersonnageAPointDeVie(int point)
            {
                PtsDeVies = point;
            }

            public override bool EstVivant
            {
                get { return PtsDeVies > 0; }
            }

            public int LanceLeDe(int valeur)
            {
                return De.LanceLeDe(valeur);
            }

        }


        public class MonstreFacile : Personnage
        {
            private const int degats = 10;
            protected bool estEnVie = true;
            public override bool EstVivant
            {
                get
                {
                    return estEnVie;
                }
            }

            // Implémentation obligatoire et substitution de la méthode abstraite "Attaque" hérité de la classe Personnage 
            public override void Attaque(Personnage perso)
            {
                int lanceMonstre = LanceLeDe();
                int lanceJoueur = perso.LanceLeDe();
                if (lanceMonstre > lanceJoueur)
                    perso.SubitDegats(degats);
            }
           


            // Ci-dessous implémentation obligatoire et substitution de la méthode abstraite "SubitDegats" hérité de la classe Personnage 

            public override void SubitDegats(int deg)
            {
                estEnVie = false;
            }

          



        }

Dans cet extrait de mon code j'ai rajouté la classe PersonnageAPointDeVie pour te montrer que j'ai même supprimé un autre polymorphisme de la méthode "Attaque".

  Par contre j'ai rajouté, à cette classe une variable "int degats" en protected pour avoir une valeur à mettre par défaut quand on a pas besoin du paramètre dans "SubitDegats(int degats)"et d'ailleurs pour cela que j'avais créer "SubitDegats() maintenant supprimé car je ne savez pas comment gérer le paramètre et quoi mettre dans ce paramètre quand celui est inutile dans certaines situations.

Bacelar, tu as raisons au lieu de dire : "évite de convertir implicitement un objet de type Joueur en objet de type Personnage" j'aurais du dire : "pour éviter qu'un objet de type Joueur se comporte comme un objet de type Personnage"

Je trouve que tu es dur par rapport à Monsieur Nicolas Hilaire, alors certes, ses cours ne sont peut-être pas parfaits mais personnellement, je les trouve, quand même, très bien car ils ont le mérite de m'avoir permis de réviser mes notions de programmation et ils m'ont aussi permis d'en acquérir des nouvelles.

Bacelar, je te remercie encore pour ton aide.

Je te souhaite une très bonne soirée.

Bien cordialement.

Aclanto

-
Edité par aclanto 8 novembre 2019 à 21:25:48

C'est déjà mieux.

Mais la surcharge de la méthode "LanceLeDe" montre que cela n'a rien à faire dans l'API de la classe, et encore moins de la rendre public.

Le De est un détail d'implémentation qui ne devrait pas être accessible de l'extérieur de l'objet.

Si vous voulez qu'un monstre touche 1 fois sur X (sans lancer de dé), etc..., vous allez changer de l'API ???

Supprimer la méthode de la classe mère et rendez là au moins "private/protected" dans la classe mère de tous les personnages qui ont besoin d'un générateur aléatoire.

Comme la classe "PersonnageAPointDeVie" n'implémente pas toutes les méthodes abstraites de sa/ses classe(s) mère(s), elle ne peut qu'être abstraite.

>j'ai même supprimé un autre polymorphisme de la méthode "Attaque"

Je ne comprends pas ce que vous entendez par cela. Ce n'est vraiment pas clair.

Si l'implémentation d'Attaque n'est pas commune à toutes les classes filles de "PersonnageAPointDeVie", on n'a pas à l'implémenter dedans, c'est tout.

>une variable "int degats"

Arrêtez de dire "variable" à tous bout de champ, c'est un champ d'une classe, c'est tout.

>en protected

Dans votre code, il est en private, et c'est très généralement mieux ainsi. Les cas où un champ en protected est pertinent sont très rares.

"private" devrait être la visibilité par défaut.

>gérer le paramètre et quoi mettre dans ce paramètre quand celui est inutile dans certaines situations.

Vous n'avez toujours pas les bases de la POO pour avoir ce type de dilemme.

Les utilisateurs de vos classes n'ont pas à savoir comment vos objets implémentent/utilisent les paramètres qu'on passe en argument.

Donc, logiquement, la méthode "SubitDegats" devrait prendre en paramètre un objet de type "Degats", par exemple. Vous pourriez ainsi facilement gérer les types de dégâts (de froid, cinétique, etc...) sans avoir à tout changer à chaque ajout d'un type.

>pour éviter qu'un objet de type Joueur se comporte comme un objet de type Personnage

C'est toujours aussi peu pertinent. La résolution dynamique des méthodes se charge automatiquement de cela.

Vous essayez de justifier une connerie avec des arguments de plus en plus moisis.

Je suis peut-être trop dur avec le cours de Nicolas Hilaire et qu'à la fin vous aurez de bonnes bases en POO, mais vous ne les avez clairement pas et je trouve que vous avez appris les mêmes conneries que ceux qui ont subi le cours de C++ d'OC qui est une calamité.

Franchement, il est hautement probable que les âneries du cours de C++ soit aussi dans le cours de C#.

Bonsoir Bacelar,

Je te remercie pour ton dernier message.

Excuses-moi avoir mis autant de temps pour te répondre j'ai eu encore plein de choses à faire ses jours-ci et j'ai beaucoup réfléchi à ton message pour faire au mieux pour l'activité en question.

A propos de cette activité, j'ai rendu ma copie et j'ai eu la note de 18/23 ce qui fait à peu près une note de 15,5/20.

Merci Bacelar, car c'est en partie grâce toi que j'ai eu cette bonne note et je remercie aussi tout celle et ceux qui m'ont aidé à avoir cette note.:

Dans cette activité, j'ai dû faire certaines choses qui t'ont déplu, Bacelar, mais l'énoncé de l'activité m'obligeait de les faire : comme par exemple la surcharge de la méthode "LanceLeDe" qui était une instruction de cette énoncé. Pareil pour la méthode "SubitDegats" l'énoncée disait bien qu'il fallait un paramètre  "int"; et pour ce dernier exemple, je trouve que l'énoncé à raison car il est plus simple mettre un paramètre "int" qu'un paramètre de type "Degats" dont la classe n’existe pas.

« Par contre je ne pense pas* que la surcharge définir une nouvelle méthode qui porte le même nom qu'une autre mais qui n'a pas la même signature. Je pense que la surcharge, d'après le cours, donne à une méthode une autre signature et peut éventuellement la redéfinir.

(* j'avais oublié le « pas ».)»

Je pense que j'avais raison car Wikipédia dit la même choses que ce cours de C#. Il me semble, Bacelar, que tu confond "Surcharge" et "Masquage". Voici le lien :

• https://fr.wikipedia.org/wiki/Surcharge_%28programmation_informatique%29

Bacelar, merci encore.

Je te souhaite ainsi qu'a tout le monde un bon week-end et une bonne soirée.

Bien cordialement.

Aclanto

-
Edité par aclanto 30 novembre 2019 à 21:28:48

>je ne pense pas* que la surcharge définir une nouvelle méthode qui porte le même nom ...
n'a pas la même signature

C'est la définition même de surcharge.

>donne à une méthode une autre signature et peut éventuellement la redéfinir.

Bin non, la redéfinition et la surcharge c'est pas du tout la même chose. Il n'y a pas "d’éventuellement".

>Il me semble, Bacelar, que tu confond "Surcharge" et "Masquage"

Non, c'est plutôt toi qui confond redéfinition (overriding) et le masquage.

L'article Wikipédia que tu donnes ne parle même pas de marquage et au contraire donne exactement les mêmes définition que moi (il ajout juste le terme de polymorphisme ad hoc que je trouve très piégeux car ayant que très peu de rapport avec le polymorphisme d'inclusion.

Bonjour Bacelar, bonjour tout le monde,

Excuse-moi de répondre si tard, j'ai été malade.

Je te remercie bien pour tout tes conseils.

Je remercie aussi toutes les personnes qui ont participées à cette discussion.

Je souhaite à toutes et à tous une très bonne année 2020, une très bonne santé et tous mes meilleurs vœux de bonheur et de prospérité.

Bonne journée à toutes et à tous.

Bien cordialement.

Aclanto

-
Edité par aclanto 10 janvier 2020 à 11:25:39