Héritage : incompatibilité static & abstract pour les méthodes

Bonjour, je poursuis ma découverte de la Poo, du c#, du framework dotnet et de visual studio... Je ne doute de rien lol...

J'ai bien compris l'incompatibilité conceptuelle entre static et abstract.

Je suis pourtant devant un cas ou cela m'aurait été utile.

Classiquement, je développe une programme de gestion d'une faune. Toute sorte d'animaux vivent, s'alimentent, se reproduisent, s’entre-tuent et meurent dans une environnement évolutif.
Pas de problème pour gérer tout cela.
La super classe Animaux contient une liste static que peuplent tous les constructeurs des classes finales.

Or, il se trouve que peuvent survenir des changements brutaux qui n'affectent plus les individus-instances des diverses sortes d'animaux, mais les populations mêmes de ces classes.

Bref, ceci:
Pièce jointe 235200

Il me faudrait donc une méthode static, appelable donc depuis la classe même de chaque classe d'animaux, mais qui soit obligatoire, donc overridée, pour garantir la cohérence du programme.
A chaque classe de définir sa propre variation de population selon les circonstances.

Comment pourrais-je m'y prendre ?

D'avance, merci.

Bonjour,

Comme tu l'as bien compris, une méthode abstract static n'existe pas et n'a pas de sens, car la notion de polymorphisme nécessite d'avoir une instance et que les méthodes statiques travaillent n'ont pas sur une instance, mais sur la classe elle-même.

Quelles sont donc les possibilités offertes ? Aucune qui réponde directement à tes attentes. Je vois cependant plusieurs approches possibles, chacune avec leurs avantages/inconvénients.

La première, c'est de ne pas utiliser une méthode statique mais une méthode classique. Tu pourras utiliser l'héritage pour forcer l'implémentation de la méthode. Inconvénient, (qui n'en n'est pas forcément un) tu dois forcément appeler la méthode en utilisant une instance.

La seconde, c'est de mettre en place un mécanisme de vérification en utilisant la réflexion. Pour chaque classe non abstraite dérivant de Animaux, tu regardes s'il existe la méthode statique que tu recherches. Si non, tu génères une erreur. Problème : cette vérification n'est faite qu'à l'exécution du code, pas à la compilation.

Puisqu'on parle de compilation, il serait bon de savoir comment sont appelées ces méthodes justement. Si elles sont appelées directement (genre Lapin.KillThemAll()) alors le compilateur pourra être ton ami. Il ne te dira pas que la classe Lapin n'implémente pas la méthode statique abstraite, mais il te dira que la méthode est manquante. Par contre, tu ne pourras pas garantir que cette méthode portera le même nom dans toutes les classes... Si les méthodes sont appelées en utilisant la réflexion, alors on se retrouve dans le même cas que précédemment, tu ne pourras avoir une erreur qu'à l'exécution, et non à la compilation.

Merci pour ta réponse.

Je me suis demandé si je ne pouvais pas passer par un interface qu'implémenteront toutes mes classes finales d'animaux.

Code:

---

1 2 3 4

interface IPopulationVariable { void VarierPopulation(Environment env); }

---

C'est depuis ma classe environnement qu'elle sera appelée en instanciant un animal.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class Environnement { //blabla...   public string SubirGlaciation() { //blabla... AffecterPopulations(); }     private void AffecterPopulations() { IPopulationVariable c = new Chien(true); c.VarierPopulation (this); IPopulationVariable l = new Lapin(true); l.VarierPopulation(this); IPopulationVariable o = new Otarie(true); o.VarierPopulation(this); //etc...

---

Ce qui m'ennuie c'est que tous mes constructeurs remplissent ma faune:

Code:

---

1 2 3 4

public abstract class Animaux : IComparable   public static List<Animaux> lstAnimaux = new List<Animaux>(); // regroupera tous les animaux créés pendant la session. // chaque constructeur y ajoutera l'objet instancié. Cela constituera l'ensemble de la faune présente (vivante) et passée (morte).

---

Or les animaux instanciés pour AffecterPopulations() ne doivent évidemment pas s'y trouver !

Je dois donc créer un constructeur qui n'ajoute pas à la list, un constructeur fantôme.

Code:

---

1 2 3 4 5 6 7 8

class Chien : MammifereTerrestre, Inageant, IPopulationVariable // un chien peut nager pas tous les mammif terrestres. { public void Chien(bool fantome) // Constructeur qui ne fait rien du tout. surtout il ne l'ajoute pas à lstAnimaux ! {}   //J'implémente la méthode de l'interface public void VarierPopulation(Environnement env){} }

---

En terme de cohérence, ça marche très bien: en codant dans Environnement, je vois de suite que les classes animaux ont ce constructeur fantôme et qu'elles ont bien implémenté l'interface.

Mais me reste une faille béante, je trouve: ce constructeur fantôme qui pourrait bien être appelé à mauvais escient pour instancier des animaux qui doivent se retrouver dans la faune ! Et là c'est imparable...

Mon raisonnement se tient-il ?

D'avance, merci.

Dans ce cas, il y a encore plusieurs approches.

La "moins bien" (selon moi) serait de mettre tout cela dans un assembly à part, et de jouer avec la visibilité du constructeur (internal sera très bien). Ainsi, tu pourras utiliser le constructeur dans ton assembly et uniquement dans ton assembly en empêchant ainsi toute utilisation en dehors.

L'autre solution, serait de remanier un peu le code, et d'introduire des collections d'animaux. Une collection génériques ListeAnimaux<T> où T est une classe dérivant de Animaux. Cette collection aurait une méthode pour instancier un animal et l'ajouter à la liste. Ensuite, il faut modifier ta classe Environnement pour ajouter autant de ListeAnimaux que tu as d'animaux ;)

PS : l'utilisation d'interface est généralement une bonne chose !

Merci François pour tes réponses. Je débute, certains concepts que tu évoques ne sont pas encore à ma portée.

Dans le fond, ce qui me gène, c'est ce constructeur fantôme qui ne peuple pas ma faune et qui pourrait se trouver appelé à mauvais escient.
Si je parvenais à le rendre private, le risque deviendrait quasi nul.

Dans mes classes d'animaux, je crée donc un méthode statique CreerAnimalFantome() qui appelle ce constructeur devenu private

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public static Animaux CreerAnimalFantome() {Chien c = new Chien(true); //appel du constructeur fantome private return c; } private Chien(bool fantome) // constructeur rendu private { }   public void VarierPopulation(Environnement env) { Console.WriteLine("Population chiens impactée"); }

---

Ps je mets en return la super class Animaux car cette méthode à vocation à rejoindre une classe statique de méthodes partagées par toutes mes classes d'animaux.


Donc, côté classe Environnement mon code pour affecter les populations devient:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public string SubirVagueFroid() {//blabla AffecterPopulations();}   private void AffecterPopulations() { IPopulationVariable c = (Chien)Chien.CreerAnimalFantome(); c.VarierPopulation(this);   IPopulationVariable l = (Lapin)Lapin.CreerAnimalFantome(); l.VarierPopulation(this); }

---

Et ça tourne impec !

Pièce jointe 235684

Est-ce-que c'est le constructeur de la classe de base Animaux qui fait l'enregistrement dans la liste static ou c'est le constructeur de chaque classe enfant qui s'enregistre explicitement ?

Bonne question Noxen !

Que justement je suis en train de me poser.

En effet, chaque constructeur de chaque classe finale se termine par ce petit bout de code:

Code:

---

lstAnimaux.Add(this);

---

pour remplir la liste static définie dans la classe mère 3 niveaux au-dessus et qui regroupe toute cette faune hétéroclite, passée ou présente (morte). Et qui me servira lors de mon apprentissage de linq...

A mesure que mon diagramme de classes se remplit d'espèces diverses et (a)variées, ça me fait une foultitude de constructeurs...

2 problèmes:

• - primo, je contreviens gravement à la loi de base de la Poo: DRY !
  
• - secundo, je cours le risque d'oublier ce petit bout de code dans un des constructeurs.
  

Je me creuse les (rares) méninges pour trouver remède à mes manquements manifestes...

Pour info, un petit bout de mon diagramme de classes.

Pièce jointe 238651

Bonjour,

Plutôt que d'ajouter l'instance de l'animal au niveau du constructeur de la classe fille (chien, chat), tu peux l'ajouter au niveau du constructeur de la classe de base (Animal).

J'ai parcouru la conversation et une chose m'interpelle dans l'architecture : La classe environnement connait tous les types d'animaux afin de pouvoir faire varier leur population. J'aurais plutôt fait une méthode abstraite au niveau de Animal qui ferait mourir l'instance avec une certaine probabilité en fonction du climat. Chaque animal pourrait donc gérer lui-même sa résistance à une periode glaciaire. Dans le fond, le climat ne connait pas les animaux mais les animaux réagissent (meurent :-() en fonction du climat. Pour ça, un animal aurait une méthode setClimat(...) et Meure(probabilité). La suppression de la liste se ferait à la mort de l'animal. Ensuite un méthode statique au niveau de Animal pourrait indiquer le nombre d'animaux par type.
Tout ça te permet d'ajouter un nouveau type d'animal sans avoir à modifier le code par ailleurs.

Un exemple (très simplifié):
Les classes animaux :

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 65 66 67

public abstract class Animal { private static Random rand = new Random(); public static List<Animal> Animaux = new List<Animal>(); public abstract void setClimat(Climat UnClimat); bool _vivant; public bool Vivant { get { return _vivant; } set { _vivant = value; if (!_vivant) Animaux.Remove(this); } }   public Animal() { Animaux.Add(this); _vivant = true; }     protected virtual void Meure(int Probabilite) { Vivant = rand.Next(100) > Probabilite; }   // Retourne la liste des animaux d'un type particulier public static List<Animal> getAnimaux(Type type) { return Animaux.FindAll(a => a.GetType() == type); }   // Retourne la liste des types d'animaux présents public static List<Type> getTypeAnimaux() { return Animaux.GroupBy(x => Type.GetType(x.GetType().FullName)) .Select(x => Type.GetType(x.Key.FullName)) .ToList(); } }     public class Chien : Animal {   public override void setClimat(Climat UnClimat) { if (UnClimat.TemperatureMoyenne < 0) { Meure(60); // 60% de risque de mourir } } }   public class Chat : Animal { public override void setClimat(Climat UnClimat) { if (UnClimat.TemperatureMoyenne < 0) { Meure(70); // 70% de risque de mourir } } }

---

Une classe climat :

Code:

---

1 2 3 4 5 6 7 8

public class Climat { public Climat(int temperature) { TemperatureMoyenne = temperature; } public int TemperatureMoyenne { get; set; } }

---

Et le code de test :

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

private void Test() { // 50 chiens for (int i = 0; i < 50; i++) { new Chien(); }   // 25 chats for (int i = 0; i < 25; i++) { new Chat(); }   Climat climat = new Climat(-5);   ShowAnimaux(); for (int i = Animal.Animaux.Count - 1; i >= 0; i--) { Animal.Animaux[i].setClimat(climat); } ShowAnimaux(); }   // Affiche les animaux private void ShowAnimaux() { Animal.getTypeAnimaux().ForEach(t => Console.WriteLine(t.Name + " : " + Animal.getAnimaux(t).Count())); }

---

Merci ebastien, très riche ta réponse.

1.- J'avais pas capté cette notion d'héritage de constructeur.
D'abord parce que je pensais que class abstract = non instanciable, donc pas de constructeur.
Ensuite parce que le nom d'un constructeur, par nature, varie et porte le nom de sa classe. Donc je ne concevais pas un héritage possible.

Mais en fait, comme un constructeur est une méthode très particulière, le compilateur reconnait leur héritage même si nom différent.

Donc voilà, si j'ai bien suivi (et ça tourne chez moi):

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

//classe mère public abstract class ObjetPere { public static List<ObjetPere> listObjPer = new List<ObjetPere>();   public Guid id_Guid; public DateTime dateCreation;   //constructeur public ObjetPere() { this.id_Guid = Guid.NewGuid(); this.dateCreation = DateTime.Now; listObjPer.Add(this); }   // classe enfant class ObjetFils : ObjetPere { public string nom;   public ObjetFils(string nom) : base() //appel constructeur classe mère { this.nom = nom; } }

---

2. Comme tu le notes finement, je faisais une grave erreur de Poo: en effet ce sont les animaux qui connaissent leur environnement et non pas l'inverse.

C'est donc très clair pour moi qu'il faut parfaitement comprendre les concepts de la Poo pour avancer en c#.

J'en profite pour recommander ce remarquable ouvrage pour s'initier à la Poo. Je ne regrette pas du tout mon achat. C'est clair et très pédagogique. Et l'auteur est une pointure académique.

Pièce jointe 239159

http://www.eyrolles.com/Informatique...-9782212135787

PS: je suis justement en train de retravailler ma classe Environnement pour y appliquer le design pattern Singleton

L'héritage c'est un peu comme un empilement, avant de créer un objet en enfant il faut créer l'objet parent qui va lui servir de support, les constructeurs sont donc appelés les un après les autres en partant du membre de la hiérarchie le plus antérieur. Et effectivement une classe abstraite ne peut être instanciée mais elle peut disposer d'un constructeur. Les classes abstraites servent à factoriser du code qui sera utiliser par plusieurs classes enfants mais elles ne sont pas obligées d'être une implémentation complète de classe à instancier. Par exemple :

Code:

---

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

interface IDisplayable { void Display(); }   abstract class Shape : IDisplayable { public void Display() { Draw(); } protected abstract void Draw(); }

---

À charge de chaque classe enfant de la classe mère d'implémenter la méthode Draw();

Il y a plusieurs choses que je voudrais signaler concernant ton approche.
Tout d'abord il me semble qu'il y a une confusion de sémantique entre les notions d'espèces et d'individus appartenant à ces espèces. Quand on parle d'une classe Chien, s'agit-il de l'espèce chien ou de l'animal chien en tant qu'individu ? Dans le cas présent tu instancies chaque animal en tant qu'individu, mais il y a des opérations que tu veux effectuer au niveau de l'espèce (gestion de l'ère glacière) ; c'est ce qui t'a amené à passer par le hack de "l'animal fantôme" pour disposer d'une méthode à "overrider". Une façon de faire les chose est comme le suggère ebastien de considérer que chaque animal réagit individuellement à la situation ; chaque animal dispose donc d'une méthode qui prendra en charge l'événement. Sinon tu peux considérer que tu gères des espèces et ce sera à l'espèce de gérer les choses sur l'ensemble de ses membres.

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

interface IAnimal { void Speak(); }   interface ISpecies { IEnumerable<IAnimal> Population { get; } void GenerateMember(); void GenerateBasePopulation(); void HandleTemperature(float temperature); }   class Dog : ISpecies { private List<Member> _population = new List<Member>();   public IEnumerable<IAnimal> Population { get { return _population; } } // Possible dans la dernière version C#   public void GenerateBasePopulation() { _population = new List<Member>(); for (int i = 0; i < 50; ++i) GenerateMember();   }   public void HandleTemperature(float temperature) { if (temperature > 0) return; int half = _population.Count / 2; for (int i = 0; i < half; ++i) _population.RemoveAt(_population.Count - 1); }   public void GenerateMember() { _population.Add(new Member()); }   private class Member : IAnimal { public void Speak() { Console.Write("Woof"); } } }

---

Par ailleurs pourquoi gérer la population à l'intérieur de la classe Animal ? Quelle est la contrainte technique ? Y a-t-il quelque chose qui est géré en coulisse dans cette classe ? Pour ce que je peux voir de ton projet il y a simplement un environnement qui gère un population d'animaux (ou une liste d'espèce, c'est à voir), mais il ne me semble pas que des contrôles doivent être faits en arrière-plan.
Pour donner un exemple inverse (le premier qui me vient) il y a l'implémentation des pointeurs intelligents en C++ (du moins ce que je subodore). Pour savoir si un objet doit être détruit on utilise un compteur de références, que je soupçonne d'être implémenté sous la forme d'une hashmap ayant en clé l'adresse d'un objet et en valeur le nombre de pointeurs vers cet objet ; à zéro l'objet est détruit.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class smart_ptr<T>{ private: static std::hash_map<T*, int> _refs; T* _obj; public: smart_ptr(T* obj){ if(_refs.find(obj) == _refs.end) _refs[obj] = 1; else ++_refs[obj]; _obj = obj; } ~smart_ptr(){ if(--_refs[_obj] == 0){ _refs.erase(_refs.find(_obj)); delete _obj; } } }

---

En l'occurrence la table de références est une nécessité intrinsèque au fonctionnement de la classe et influence le comportement des instances créées, ce qui ne devrait pas être le cas pour les animaux.

Merci pour vos réponses... même si certaines sont encore du chinois pour moi...

Je débute en Poo et en c#. Je ne suis pas informaticien.

Je développe depuis des années en vba surtout pour Excel, pour moi et pour (avec) des collègues. On aimerait un outil particulier pour la prochaine rentrée et pour cela il nous faut du plus lourd...

Donc on se forme à deux, en autodidacte.

---------------
Pour mon programme, en fait, je travaille avec deux classes "main": une bac à sable pour apprendre et une principale pour mon programme de faune.

--------------

Vous l'avez compris , au lancement s'instanciera un Environnement initial (classe singleton) avec une faune initiale.
Les espèces y interagiront et les individus d'espèce aussi entre eux (reproduction).Et ils mourront.

Cet environnement subira des changements brutaux de Climat (4 classes internes). Les populations d'espèces y réagiront aussi brutalement (croissance/décroissance: mort ou fécondité accrue des femelles).

Avec du random un peu partout.
Voilà en gros.

------------

Toute ma faune, présente ou passée, sera contenue dans cette liste static de la classe supérieure Animaux.
C'est là que mon programme ira chercher, par espèce, les individus en vie pour en faire mourir une partie ou au contraire les faire se reproduire davantage.

-------------

Pourquoi conserver trace des générations défuntes, me demanderez-vous ?


Pour ceci entre autres:

Code:

---

1 2 3 4 5 6 7 8 9

public abstract class Animaux : IComparable, IPopulationVariable, Iproie { public static List<Animaux> lstAnimaux = new List<Animaux>(); // regroupera tous les animaux créés pendant la session. // qu'ils soient encore en vie ou déjà mort internal bool vivant; internal Guid Id_guid; internal Guid Mere_Id_guid; //une mère transmet son id à ses enfants internal int nbrePortee = 0; internal int nbreEnfants = 0;

---

Une femelle qui met bas transmet son Id à ses rejetons. Pour ceux qui ont des notions en bio, c'est l'ADN mitochondrial.

Cela devra me permettre, en bout de course, de reconstituer l'arbre généalogique de tout individu, par les mères. Ou à l'inverse de reconstituer toute la descendance transgénérationnelle d'une femelle !
Je sens que cela va bien m'occuper dans quelques semaines/mois quand j'aborderai Linq...

Une notion qu'on recherche en architecture logicielle est celle de couplage faible, c'est-à-dire limiter les contraintes et dépendances fortes. Dans le cas présent ta liste d'animaux est intrinsèque à ta classe, en d'autres terme tu ne peux pas t'en passer, tu es obligé de passer par elle. Pour l'instant tout va bien. Mais que se passera-t-il quand tu voudras gérer deux listes d'animaux indépendantes (par exemple dans deux environnements différents, ou une liste "réelle" et une liste "virtuelle", pour faire un calcul) ?
Autre exemple : si tu persévère dans ce domaine tu seras amené à utiliser des tests unitaires et des objets "mock" (des contrefaçons). Mettons qu'on décide qu'un chien a 60% de chance de survivre à une période glacière.

Première implémentation :

Code:

---

1 2 3 4 5 6 7 8 9

class Chien { public Chien() { EstVivant = true; } public bool EstVivant { get; set; } public SubirVagueDeFroid() { if(new Random(DateTime.Now.Ticks).Next(1, 100) > 60) EstVivant = false; } }

---

Ici on ne peut pas tester si cette fonction est toujours valide (par exemple que personne n'a accidentellement remplacé le 60 par un 6 ; et ça peut arriver avec des remplacements globaux).

Deuxième implémentation :

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

interface INumberGenerator { int Next(); }   class RandomNumberGenerator:INumberGenerator { private Random _rand = new Random(DateTime.Now.Ticks); public int Next() { return _rand.Next(1, 100); } }   class SpecificNumberGenerator:INumberGenerator { private Func<int> _func; public SpecificNumberGenerator(Func<int> func){ _func = func; } public int Next() { return _func(); } }   class Chien { public Chien () { EstVivant = true; } public bool EstVivant { get; set; } public SubirVagueDeFroid(INumberGenerator generator) { if(generator.Next() > 60) EstVivant = false; } }

---

En code de production :

Code:

---

1 2	Chien chien = new Chien(); chien.SubirVagueDeFroid(new RandomNumberGenerator);

---

En code de test :

Code:

---

1 2 3 4 5

Chien chien = new Chien(); chien.SubirVagueDeFroid(new SpecificNumberGenerator(() => 60); Assert.IsTrue(chien.EstVivant); chien.SubirVagueDeFroid(new SpecificNumberGenerator(() => 61); Assert.IsFalse(chien.EstVivant);

---

Merci Noxen pour ce très bon exemple d'implémentation prenant en compte l'utilisation des tests unitaires.

De tout cœur un grand merci pour votre disponibilité et la qualité de vos réponses. Et pour y ajouter du code de pro!

Grâce à vous j'avance vraiment dans ma compréhension de la Poo.

Citation:

---

Noxen: Une notion qu'on recherche en architecture logicielle est celle de couplage faible, c'est-à-dire limiter les contraintes et dépendances fortes.

---

Voilà bien une notion qui m'échappait. Je commence tout doucement à la comprendre.
J'ai été voir sur wiki: https://fr.wikipedia.org/wiki/Couplage_(informatique)

Puis j'ai trouvé ici un très bon article de rawsrc sur la dépendance entre classe: https://blog.developpez.com/rawsrc/p...es_classes_poo

Si vous connaissez d'autres ressources sur le web, je suis preneur...

Je commence à entrevoir l'intérêt des interfaces dans cette optique, par exemple.

-------------

Une autre notion clé, c'est la factorisation. Je dois encore progresser. Mais disons que j'ai déjà bien dressé mon cerveau à m'alerter quand j'écris du code que j'ai déjà écrit (DRY).

------------

Enfin, dernière question, je pense qu'un passage par Uml m'est nécessaire ?

Une âme charitable m'a refilé ceci:
Pièce jointe 240007

Cela devrait me suffire amplement ?


Et aussi ceci:
Pièce jointe 240016

J'ai bien compris que les auteurs sont des pointures à la base de l'UML. Mais est-ce toujours up-to-date ? (copyright 1999)