Question d'héritage en c#

Salut à tous,
Non, je vous rassure, je n'ai pas besoin d'un notaire...;)

J'avais commencé un projet personnel en C#/wpf /xaml et comme je l'avais mal préparé, je le recommence depuis le début.

Il sagit une application PC me permettant de gérer des aquariums, et plus précisément le suivi des populations et des entretiens....Pour cela, j'ai redéfini ce que je veux pouvoir faire, et comment je souhaite l'afficher, mais c'est au niveau développement que je seche, je vous éxplique:

Je souhaite créer des poissons "théoriques" qui serviront de modèle aux poissons réels qui seront affectés aux aquariums que j'aurais crées.

Concrétement, l'individu que je viens d'acheter doit afficher dans l'interface, les caractéristiques du modèle théorique auquel il est lié mais aussi ces infos personnelles. Pour info, les caractéristiques ne sont pas la simplement pour faire joli, mais me permetront de réaliser des tests de compatibilité avec les autres espèces, ainsi qu'avec les différentes qualités d'eau .

Question: dois je créer une super classe "Individu" qui englobe toutes les caractériques théoriques + les éléments personnels liéés à l'indivu (date de naissance, prix chez le fournisseur, dernière maladie etc…)

Ou alors dois je créer une classe "individu" qui hérite de la classe "théorique"? Je suis débutant, j'ai bien compris le principe d'héritage, mais malheureusement, je ne comprend pas quand je "dois" l l'utiliser.

Pour aider à la compréhension de mon projet, j'ai réalisé un "pseudo diagramme"
Pièce jointe 146270

Merci à tous

Dans ce cas-ci, tu n'es pas "obligé" d'utiliser l'héritage.

Si tu veux, utilise une classe mère, par exemple Animal, dans laquelle tu as toutes tes caractéristiques principales.
Ensuite, crée tes classes filles, poisson, amphibien, .... qui hérite donc de la classe animal. Dans ces classes, tu peux ajouter toutes les caratéristiques secondaires (par exemple à poisson, euh j'ai pas d'exemple la tout de suite xD donc j'invente et je dis, un boolean pour savoir s'il est rare ou non :D)
(Je te laisse choisir les noms ^^)

Ensuite, tu peux créer un individu

Exemple,
Poisson individuPoisson_1 = new Poisson(...);
Amphibien individuAmphibien_2 = new Amphibien(...);


Cependant, je viens de voir ton schéma et à je suis un peu perdu :/

Ha, j'esperais que mon shéma soit le plus simple possible ...:D

bon en théorie, dans un premier temps, je souhaitais créer une fiche "théorique" de renseignement sur une espece de poisson contenant
nom, espece , famille ,origine géographique, mais aussi des détails sur la température et le Ph de l'eau dans son milieu naturel.

dans une second temps, j'achete un poisson et je veux l'enregistrer dans mon appli.
je vais chercher dans un menu déroulant le nom du poisson que j'ai préalablement créé, et je complete sa fiche "personnelle" en ajoutant des détails sur la couleur, la taille, le sexe etc....

et je pensais donc que l'héritage me serait utile pour "transférer / lier" les infos de la fiche Thérorique à la fiche personnelle.

OK.

Tu as donc besoin :
d'une liste de Poissons à afficher en tant qu'espèce
&
d'une liste de Poissons en tant qu'individu

Crée donc une interface IPoisson qui contient les variables communes à tout tes poissons (espèce, ...)
Crée donc une classe Poisson, hérite de la classse IPoisson.
Crée ensuite une classe Individu, qui hérite de Poisson et qui contient en plus les variables uniques à chaque poisson (âge, ...)

C'est ce que tu veux ?

ça y ressemble fortement.
Quel est l'interet de créer l'interface Ipoisson puisque ma classe Poisson va reprendre toutes les variables cette interface?
je n'ai jamais vraiment compris l'utilité des Iclasses.
en tout cas, merci pour tes réponses.

Ici, je n'y vois pas d'utilité, maintenant, c'était à titre d'exemple, au cas où, il y aurait des choses à ajouter, cette classe trouverait peut-être une utilité.

une interface, c'est surtout un "contrat".

Si j'ai bien tout compris tu ne devrais avoir besoin ni d'héritage ni d'interface.

Au contraire tu as besoin de composition, ce qui n'est pas apparent parce que le modèle n'est pas parfaitement bien défini :
- ce que tu appelles "poisson théorique" je l'appellerais "genre" ou "type" avec en effet des caractéristiques communes à tous les membres de ce "genre" (nom, espèce...)
- chaque poisson encapsule une instance de "genre"
- la liste des différents genres est affichée dans l'interface
- quand l'un est sélectionné tu crées un nouveau poisson en lui affectant le genre choisi et tu complètes les propriétés spécifiques au poisson

Code:

---

1 2 3 4 5 6 7

Poisson poisson = new Poisson { Genre = genreChoisi, Taille = tailleChoisie, Couleur = couleurChoisie ... };

---

C'est vraiment le plus simple parce qu'il y a potentiellement des milliers de genres (bon OK peut être des centaines seulement pour l'aquariophilie) et tu ne veux pas écrire toi même autant de classes. :)

outch, juste au moment ou j'avais compris l'interet des interfaces...:D

Merci Seriousme pour cette dernière info.

dans ton exemple, Genre est une classe? car je vais avoir besoin des caractéristiques générales du genre dans différents test par la suite. Si c'est bien une classe, c'est ce que j'avais fait la première fois:

une classe pour les genres (Poisson théorique)
une classe pour les individus (Poisson réellement possédé)

à chaque nouvel achat de poisson, je créais un nouvel "individu" avec les caractéristiques générales liées au genre + les données spécifiques taille , sexe, couleur prix etc...

Moi qui espérais pouvoir enfin appliquer le concept d'héritage… ;)

J'ai peut être une possibilité au niveau des "évènements".
Dans mon projet, je souhaite pouvoir suivre différents types d'évènements. Certains concernent les individus…(naissance, mortalité, maladies…) d'autres sont liés aux équipements (nettoyage filtration) ou alors quelques uns peuvent être rattachés à un aquarium (Changement d'eau).

Tous ces évènements ont des comportements différents, certains sont ponctuels, d'autres sont réguliers (voir programmable à l'avance). Et je suppose que c'est ici que je vais pouvoir appliquer l'héritage (et peut être même l'Interface).

Pour rappel, mon projet n'à pas d'objectif commercial, c'est juste un projet "éducatif personnel"

Genre est en effet une classe, dont les instances seront les différents genres de poissons : poisson rouge, poisson à plume, poisson à lunettes...
Si tu connais à l'avance la plupart des genres et que ça évolue peu tu peux les mettre en dur dans ton code, sous forme d'instances statiques :

Code:

---

1 2 3 4 5 6 7 8

class Genre { public static readonly Genre PoissonRouge = new Genre { Nom = "Poisson rouge", Region = "Partout" }; public static readonly Genre PoissonAPlume = new Genre { Nom = "Poisson à plume", Region = "Là où il y a des éléphants roses" }; public static readonly Genre PoissonALunettes = new Genre { Nom = "Poisson à lunettes", Region = "Dans les bibliothèques" }; ... public static readonly IList<Genre> GenresConnus = new List<Genre> { PoissonRouge, PoissonAPlume, PoissonALunettes }; }

---

Et dans l'interface graphique tu affiches la liste Genre.GenresConnus.

Sinon utilise un fichier de configuration (typiquement du XML) et lit le au chargement de l'application pour alimenter la liste Genre.GenreConnus (dans le constructeur statique de Genre par exemple).

Pour le reste tu auras en effet besoin d’événements, donc tu pourras dire que tu as aussi fait du design pattern observateur, et ça c'est classe :lun: ;)

Dans ma premiere version, j'avais effectivement enregistré toutes mes tables dans des fichiers xaml que je chargeais en mémoire au démarage de l'appli.

C'est sur les "liaisons" entre les tables et l'affichage que j'avais des problemes (wpf est plutot simple, mais combiné avec du c#, j'avais du mal à savoir comment coder, (code behind Vs code wpf/xaml)

Pour les design pattern, je vais donc "observer":mrgreen:
en tout cas, merci pour l'info.