Bonjour,

J'ai une question car j'ai un doute à propos de l'appel du constructeur de la classe de base.

J'ai compris qu'en écrivant : base() Cela appelait le constructeur de base de la classe mère, mais comment fait on pour appeler un constructeur surchargé de la classe fille + le constructeur surchargé de la classe mère ?

J'ai trouvé un méthode sur le net mais j'ai un doute sur la lisibilité du coup :

http://gyazo.com/7e7778a84c523ee52f8fbf14b7ebae35

Je sais pas si ce que je fait correct ou si je suis à côté de la plaque

Je code en c# si jamais.

Bha c est moche et illisible mais ça parait correcte. Suffit d essayer et de regarder si tout est bien instancié

Justement, vu que je débute j'ai tendance à me dire qu'il y a une meilleure manière quand je vois que c'est dégueulasse

La methode d'appel a la classe parente n'a rien de "degueulasse", par contre des constructeurs avec 25 millions de parametres sans relation aucune, ca c'est pas tres propre

Une approche par "componentisation" serait bien plus claire.

Componentisation ? Je vais rechercher, merci.

EDIT : Sinon je tiens à préciser que je ne disais pas que l'appel était dégueulasse juste ma façon de faire.

C'est un classique cette manière de faire. Dans la liste d'initialisation, tu fais un appel a base et dans les paranthese, tu fais construit ton objet. Petit test (j'en profite pour test les tabs de respawn).

class A 
{
   public A(int b) : baba(b) {};
   protected int baba;
}

class B
{
  //Quand tu crée B tu fais un appel au constructeur de A
  public B(int b, int c) : base(b), coco(c) {};
  private int coco;
}

J'ai peur de ne pas tout comprendre, à quoi correspond baba puis coco ? Je pensais qu'on était obligé d'appeler base pour appeler explicitement le constructeur de la classe mère.

LGV, pour la "componentisation" j'ai fait quelques recherches, cela reste complexe donc je pense que je vais devoir re-lire et y revenir plusieurs fois pour commencer à assimiler les choses. Par contre, est-ce que les paramètres que j'ai mis n'ont vraiment pas de sens pour toi ?

J'ai compris que cette façon de faire était pour faire une sorte d'arbre en cascade, qu'on devait mettre dans la classe mère ce que les classes filles auront en commun puis de spécialiser au fur et à mesure qu'on descend. La classe Personnage étant vaste et fait appel à des objets qui seront complexes, je trouve ça compréhensible qu'il y ait autant de paramètres.

Comment fais-tu de ton côté ? Cela m'intéresse

Les parametres ont du sens, mais il n'y aucune cohesion ; il y des stats, et ca va de pvActuel a pvMax en passant par argent et experience

Certaines stats sont liees (pvActuel <> pvMax), d'autres pas du tout (pvActuel ? argent)

Il y a un decoupage fonctionnel des concepts, mais pas un decoupage au sens semantique. Du coup le code design est assez pauvre, et on va vite se retrouver avec un cas de "monolith" ou la classe fait un peu tout et n'importe quoi

En travaillant sur le sens des fonctionnalites, je proposerai plus une architecture avec les composants suivants :
- Health ; qui gere les pv, pvMax, qui gerera la logique quand on se soigne ou qu'on prend des coups au combat, etc.
- Inventory ; l'argent va surement servir a acheter/vendre des items ou services, donc avoir qqch pour gerer le container et les "monnaies" du joueur. Ca gerera la logique pour s'assurer que l'inventaire n'est pas plein quand on achete un objet, qu'on recoit bien l'argent quand on en vend un, etc.
- etc.

Et la classe Joueur devient une simple aggregation de ces composants. De plus je rajouterai aussi des composants pour les ressources de l'entite (sprites, animations, effets sonores, hitboxes, etc.), des composants pour les logique du jeu (position, orientation, vitesse, etc.), les modes de controles (gamepad, remote si network, etc.)

De plus l'approche composant est bcp plus flexible ; si par la suite tu as besoin d'un PNJ marchand qui fait presque tout ce qu'un Joueur fait, ben tu enleves juste qq composants. Ou si tu as besoin d'une classe qui peut lancer des sorts ; tu rajoutes un composants pour cette mecanique de gameplay, etc.

Bref, c'est plus modulaire que des listes de parametres a rallonge.

Au passage, l'heritage est une tres mauvaise idee pour essayer de decrire des specialisation d'entites.

On prend souvent l'exemple de la classification des animaux. On demarre tout en haut avec une classe Animal ; et puis on a des classes filles avec Mammiferes d'un cote et Ovipares de l'autres. Et la un rigolo te demande ou mettre l'Ornithorynque, un des rares mammiferes qui pond des oeufs...

Pareil avec les vehicules ; on demarre tout en haut avec Vehicule ; on specialise en Avion, Bateau et Voiture. Un avion ca a des reacteurs et des ailes, et une voiture ca a un moteur a explosion et des roues. Et quand on veut mettre la Batmobile, voiture a turbine, ou la 007 Car, voiture qui vole, ca ne rentre pas...

Alors on se retrouve a faire monter des concepts... en faire descendre d'autres... Changer les classes... Jouer avec la classification... On peut rajouter les Monotremes aux animaux, ou les "avions a reaction" et "voiture a explosion" aux vehicules pour separer les concepts... On se retrouve a faire des heritage en diamant dans tous les sens, etc. Et ca ne tient pas la route.

L'heritage ne doit PAS etre utilise pour capturer des classifications ! C'est une TRES mauvaise idee. L'heritage sert a factoriser des fonctionalites semantiques.

Pour toutes les fonctionalites propres, on fait des composants. Bcp plus modulaire, et facile a gerer dans des systemes data-driven.

Je tiens à préciser que je ne code pas tout ça dans le but d'en faire un jeu complet. J'ai un peu commencé à programmer le fameux jeu du plus ou du moins (on passe un peu tous par là) . Après avoir fini ce projet, cela me frustrais un peu de ne pas avoir pu en savoir plus sur les classes, les propriétés etc...

Je me suis tourné donc du côté d'un RPG textuel, mais pas dans le but d'en faire vraiment un jeu mais pour essayer de voir comment tout cela marche. Je suis en venu en parler du coup pour en apprendre plus et avoir la chance de parler avec des gens qui s'y connaissent plus pour éviter de prendre de mauvaises habitudes. Le problème, c'est qu'on entend souvent qu'il faut faire ceci pour apprendre d'une autre personne qu'il ne faut pas faire cela donc ça reste un peu confus

Je n'avais jamais entendu parler des composants il me semble, c'est un peu comme des pièces qu'on peut ajouter ou enlever à des classes dans l'idée ? Est-ce que c'est dans la même idée que les interfaces ou est-ce que c'est encore une autre chose ?

Et en effet, tu fais bien d'en parler, car l'exemple des animaux, c'est ce qui revient souvent et donc ce que j'ai pu en tirer c'est que cela servait de spécialisation, mais du coup tu me dis qu'il ne faut pas classifier dans cette idée là, encore une nouvelle chose.

À moins que je comprends mal, quel serai un petit exemple de bonne utilisation d'héritage ? Désolé pour toutes ces questions mais cela reste très nouveau pour moi et j'essaie d'éviter les mauvaises habitudes. Merci d'avoir pris de ton temps pour donner des conseils, j'espère que cela ne servira pas qu'à moi aussi.

Heritage et composition sont des concepts faciles a comprendre, mais difficiles a *bien* utiliser, car au debut sans s'etre confronte aux problemes pratiques on ne voit pas necessairement les avantages d'une approche sur l'autre.

C'est bien de s'interesser, car bien programmer c'est avant tout utiliser les bon outils ; c-a-d les bonnes technologies, mais aussi les bons concepts.

Un bon exemple d'heritage utile, c'est le design pattern Strategy ( http://fr.wikipedia.org/wiki/Strat%C3%A9gie_%28patron_de_conception%29 ) ; l'idee est d'encapsuler un bloc de logique, de maniere a pouvoir en implementer plusieurs variantes qui repondent a la meme interface.

Par exemple dans un jeu, on peut avoir un entite qui, avec les composants qui vont bien, represente un personnage. On peut donner a cette entite un controller ; selon que c'est un personnage joueur ou non joueur, ce sera un controlleur qui repond a des inputs (actions traduites depuis un gamepad, clavier, etc.) ou a un IA (actions traduites depuis une logique). Et *tout* le reste reste reutilisable

Pour faire "simple", souvent on a tendance a eclater les donnees sous forme de composants, et a eclater la logique sous forme d'heritage, pour maximiser reutilisabilite et flexibilite. Ca n'est pas tout a fait vrai, mais cette idee globale marche dans 90% des cas

Cela dit c'est une discussion relativement avancee qui touche au code design. La plupart des gens avec une formation dans l'informatique et seulement qq annees d'experience n'y voit d'ailleurs pas tres clair. Et trouver des bons "software architects" est difficile.

Si tu comprends les bases, deja, ca sera mieux que la majorite des framework mis en place pour de nombreux projets amateurs.

Que veux tu apprendre ? A faire du code propre avec un bon design ? Ou apprendre a coder et donc savoir comment faire de l'héritage ou des agrégations... etc ? Pour le moment, je vais répondre a trois questions.

Je n'avais jamais entendu parler des composants il me semble, c'est un peu comme des pièces qu'on peut ajouter ou enlever à des classes dans l'idée ?

Imagine que ton personnage soit un objet. L'idée de composant (ou l'idée du patron entity componnent) est de faire en sorte que tu peux "attacher" des objets a ton personnage.

Exemple : tu ramasse une arme, tu rajoute un composant arme dans ton objet personnage. Tu lâche ton arme à terre ou tu la jette, tu retire l'arme de l'objet.

Comment sa fonctionne ? Voici une petite explication : Tous tes objets dérivent d'une classe composant. A partir de là, tu peux te faire une structure de donné qui contient tout et n'importe quoi qui dérive de composant. Après tu peux appeler les bonnes méthodes dessus.

 //Notre vecteur qui pourrait representer notre inventaire
vector<Composant*> mesComposant; 

//Notre arme qui se trouvera par terre
Composant* arme = new Arme();

//On ramasse l'arme et on tire
mesComposant.push_back(arme);
mesComposant.front()->tirer(cible); 

Ce code est loinnnnn d'être complet (cible pas déclarer et j'appelle la méthode de l'arme sans aucune vérification) et n'hésiter à me corriger si je dis des conneries.

À moins que je comprends mal, quel serai un petit exemple de bonne utilisation d'héritage ?

Tu utilise l'héritage quand tu vois que tu as des abstractions à faire qui sont nécessaire. Un exemple, si tu fais une conception pure orientée objet, de créer un switch case avec polymorphisme. Tu as besoin de faire de l'héritage. Un autre serait de faire des descriptions de compte bancaire qui possède la même base et des description plus précise pour chaque type de compte (enfant-trésor, étudiant).

Mais de meilleur exemple apparaisse souvent quand tu fais de la conception logicielle.

J'ai peur de ne pas tout comprendre, à quoi correspond baba puis coco ? Je pensais qu'on était obligé d'appeler base pour appeler explicitement le constructeur de la classe mère.

Baba est un int protégé de ma classe A, et coco un int privé de ma classe B. On utilise base() pour appeler le constructeur de base. Je lui envoi en paramètre b et j'utilise l'autre paramètre pour instancier coco. Si tu ne comprend toujours pas, je te ferais un exemple plus propre (il est a l'arrache avec le minimum de ligne).

Vous pouvez corrigé mes coquilles s'il y en a

LDV Bon, je continue d'en apprendre, après c'est vrai que je ne comprends pas tout, j'ai l'impression des fois de sauter des étapes sans m'en rendre compte mais je ne saurai pas trop comment expliquer Merci pour le lien en tout cas, il y a un exemple pour le c# donc ça me parle déjà beaucoup plus

123_bou

Que veux tu apprendre ? A faire du code propre avec un bon design ? Ou apprendre a coder et donc savoir comment faire de l'héritage ou des agrégations... etc ?

Un peu des deux, je me disais que quit à en apprendre un peu plus, autant apprendre à le faire proprement.

Si je comprends bien , cela se gère comme un inventaire qui spécialise la classe selon son contenu ? J'ai déjà vu (très peu) l'utilisation du vector et des symboles "*" et "->" quand j'avais survolé un peu le c++ mais je les ai plus revu en c#. Cela s'utilise aussi ou c'est différent ?

Bon, ne te soucis pas trop de * et ->. C'est spécifique au langage qui utilise les pointeurs. En C# et Java, tu ne les verra pas.

En gros, le vecteur est un tableau qui contient des componnent et quand tu appelle une méthode dessus, il va, par polymorphisme, appeler la bonne méthode de la bonne classe.

Si tu veux voir des vecteur en C#, il porte le nom de List. A ne pas confondre avec LinkedList qui est différent dans son fonctionnement. Exemple rapide d'utilisation de List en C# :

using System.Collections;
using System.Collections.Generic;

class A
{
  private List<int> maListe;
  
 public void FaireDesChoseDansMaListe(int a, int b)
  {
    maListe.Add(a); //Ajoute a dans ma liste
    maListe.Remove(b);  //Retranche b de ma liste si b existe
  }
 //Pour plus, voir la doc de msnd sur les Liste
}

Bon, si tu veux des endroits pour te diriger pour en apprendre plus, je te conseil developper.com, je ne sais pas s'ils ont des bon tuto sur le C# mais c'est un bon site.
http://dotnet.developpez.com/csharp/

Pour apprendre a faire du bon design en code, je conseil d'apprendre 10-15 patrons de conceptions, parmi les plus connus. http://fr.wikipedia.org/wiki/Patron_de_conception

Pour les concepts de base (polymorphisme, héritage, agrégation, composition), s'il y a des trucs que tu capte pas trop, tu peux toujours venir poser des questions.

Ah oui ! Il me semble avoir un peu vu les listes Pour les pointeurs, est-ce que cela peut être un handicape dans le C# de ne pas les manipuler manuellement ? Merci pour le lien Wiki en tout cas, j'y vois un peu plus clair maintenant que je peux voir certains patron. Après il ne me semble pas qu'ils les montrent vraiment dans la page ou alors j'ai mal vu, j'imagine qu'une recherche google s'impose.

Polymorphisme il faut que je revois, héritage ça va encore, mais il me semble que je n'ai pas encore vu d'agrégation et de composition.

Pour les pointeurs, est-ce que cela peut être un handicape dans le C# de ne pas les manipuler manuellement ?

Non pas vraiment. Il y a deux grosses écoles en informatique. Ceux qui vivent sans manipuler des pointeurs et les autres. Mais pour l'instant, ne te dérange pas avec ca.