Discussion :

[Invité]

Bonjour à tous !

Je rencontre actuellement un problème avec l'héritage dans mon projet que j'ai résumé dans le schéma suivant :



En effet, je ne parviens pas à implémenter la fonction isSwordsDrawn() car je ne peux accéder à mSwordsDrawn...

Que puis-je faire ?

Merci d'avance !

[Invité]

si tu manipules un Player*, tu ne peux pas appeler isSwordDrawn car c'est pas une méthode de Player.

Tu peux faire un dynamic_cast pour convertir ton Player en SinbadCharacter (qui pour le coup présente bien la méthode isSwordDrawn)

Tu peux sinon écrire simplement SinbadCharacter* mplayer=new SinbadCharacter

[Invité]

Ok merci !
Je suis en train de réfléchir à ce que tu me dis et je me demande si il est possible de connaitre exactement le type de la classe de mon pointeur ?

Évidemment à part utiliser une variable dans la classe de base que je modifierais dans le constructeur de chaque classe dérivée ?

Merci encore !

Edit: résolu.

[screetch]

dans ce cas la tu n'as pas besoin d'heritage, l'heritage est fait pour traiter de maniere unifiee des objets de types differents.
Soit:
- tu sais que ton player est un SinbadCharacter et il n'y a pas besoin de le traityer comme un Player generique
- tu ne sais pas que c'est un SinbadCharacter car ca pourrait etre quelque chose d'autre et dans ce cas tu ne dois pas acceder a des methodes specifiques de SinbadCharacter.

Revois ton design et repond a cette question: le PlayerManager, sait-il que c'est un SinbadCharacter?

[3DArchi]

Bonjour,

Un dynamic_cast est signe d'un problème de conception ( en général, ça aboutit à violer le open/close principle).

Soit c'est la mauvaise abstraction qui est manipulée (ce qu'indique Screetch) : la classe utilisatrice PlayerMgr doit elle manipuler par l'interface de base Player ou par l'interface dérivée Sinbad ?

Soit l'abstraction manipulée est incomplète : PlayerMgr n'a-t-il pas en réalité besoin d'un IsWeaponDrawn sur une interface Player ( au besoin mise en œuvre par Sinbad comme un isSwordsDrawn) ?

Soit la responsabilité est mal distribuée dans le contrat : ce qu'essaie de faire PlayerMgr avec isSwordsDrawn relèverait mieux d'une autre fonction plus complète du Player. Typiquement if(!player->IsSwordsDrawn()){player.DrawSwords();}) à remplacer par un player.DrawSwords(); direct, à charge de DrawSwords de vérifier ce qui doit être fait en fonction de son état interne.

ou encore, carrément un design inapproprié : peut être un visiteur conviendrait-il mieux ?


Quelques liens :

F.A.Q : Pourquoi mettre en œuvre un héritage ?
F.A.Q : Qu'est-ce que le LSP ?

Open/Close principle chez Emmanuel

Et pour le plaisir, puisque dans PlayerMgr, il est fort à parier que Mgr est une contraction pour Manager et non pour Monseigneur comme il se doit, à lire aussi : De la gestion des gestionnaires.

Enfin, juste une remarque sur le nom SinbadCharacter. Chez moi, Sinbad fait écho à un personnage, pas à un archétype (disons dans ce qui ressemble à un jeu. A moins que ton jeu use d'antonomase mais cela me semblerait maladroit en terme de maintenance). Donc SinbadCharacter serait une instance de Player et non une classe dérivée. Une classe dérivée serait Sailor par exemple.

[Invité]

Un dynamic_cast est signe d'un problème de conception

Décidément

Sinon, c'est pas parce qu'on peut se passer du dynamic_cast qu'il ne faut pas le connaitre... ne serait-ce que pour se questionner sur son utilisation.