Discussion :

[SofEvans]

Bonjour,

Alors voila mon problème.

Je créer une classe arme. Je fais toutes les fonctions membres et tout...
Puis, je fais la fonction ChangerModeArme qui me permettra de selectionner entre "auto" et "single".
Je me dit alors qu'un fusil sniper ou même un fusil a pompe n'ont pas de sélecteur.
Je décide donc de créer (pour la première fois certes) un héritage.
J'ai donc une classe mère ArmeModeFixe et une classe fille ArmeModeSelectif qui herite de la précédente avec la fonction membre ChangerModeArme.

Mon problème vient ensuite.

Je voudrais créer une sorte d'arsenal.
Je créer un tableau contenant sur chaque ligne l'adresse d'une arme, peu importe quelle soit de type fixe ou sélectif.

Or, si je créer ce tableau avec le type ArmeModeFixe, il me crache qu'il ne connait pas la fonction ChangerModeArme et si je créer le tableau avec le type ArmeModeSelectif, je ne peut pas y incorporer les occurrences de ArmeModeFixe.

J'ai vraiment dû louper un chapitre mais je sais pas lequel

Quelqu'un peut il me donner la methode afin de créer cette arsenal et afin de pouvoir utiliser toutes les fonctions des deux classe ?
Faut-il faire une surcharge ?

Merci de m'avoir lu.

[koala01]

Salut,

Déjà, il est difficile de soutenir qu'une arme à cadence de tir réglable soit une arme à cadence de tir fixe, parce que, justement, la cadence de tir est réglable pour le premier et non pour le deuxième

Soutenir l'inverse est d'ailleurs tout aussi difficile pour la même raison

Il ne me semble donc pas opportun de faire hériter les armes à cadence de réglable des armes à cadence de tir fixe

Par contre, ce qui est beaucoup plus facile à soutenir, c'est le fait que les armes à cadence de tire réglables et les armes à cadence de tir fixe sont... des armes à feu (par opposition aux armes blanches, contondantes et autres )

Et il pourrait très bien être de la responsabilité du type "armes à feu" de préciser si, oui ou non, la cadence de tire est réglable

L'idéal serait donc une classe "ArmeAFeu", fournissant l'interface commune aux armes à feu des deux types ("ArmeACadenceReglable" et "ArmeACadenceFixe"), à savoir:

• Une fonction permettant de connaitre le nombre de munition en magasin
• Une fonction permettant de recharger le magasin
• Une fonction permettant de tirer
• Une fonction virtuelle (éventuellement pure) (méthode) permettant de savoir si l'arme est à cadence fixe
• Une fonction virtuelle (éventuellement pure) (méthode) permettant de savoir si l'arme est à cadence réglable

ArmeACadenceReglable et ArmeACadenceFixe héritant tous les deux de ArmeAFeu

Cela pourrait prendre la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
ArmeAFeu
{
    public:
        ArmeAFeu();
        virtual ~ArmeAFeu();
        unsigned int ballesRestantes() const;
        void recharger();
        void tirer();
        virtual bool estACadenceFixe() const = 0;
        virtual bool estACadenceReglable() const = 0;
    private:
        /* les membres qui vont bien */
};
ArmeACadenceFixe : public ArmeAFeu
{
    public:
        ArmeACadenceFixe();
        ~ArmeACadenceFixe();
        /* il faut redéfinir les deux méthodes virtuelles pures pour pouvoir
         * instancier cette classe
         */
        virtual bool estACadenceFixe() const ;
        virtual bool estACadenceReglable() const;
}
/*elles seront implémentées sous la forme de  */
bool ArmeACadenceFixe::estACadenceFixe() const 
{
    return true;
}
bool ArmeACadenceFixe::estACadenceReglable() const
{
    return false;
}
 
ArmeACadenceReglable : public ArmeAFeu
{
    public:
        ArmeACadenceReglable ();
        ~ArmeACadenceReglable ();
        /* il faut redéfinir les deux méthodes virtuelles pures pour pouvoir
         * instancier cette classe
         */
        virtual bool estACadenceFixe() const ;
        virtual bool estACadenceReglable() const;
        /* cette classe a une fonction particulière permettant de
         * sélectionner la cadence de tir
         */
        void changeCadence()
        {
            tirRapide ^= 1;
        }
        /* et un autre permettant de savoir si l'arme est réglée en tir rapide
         */
        bool enTirRapide() const{return tirRapide;}
    private:
        /* sans oublier le membre qui maintient cette information */
        bool tirRapide;
}
/*elles seront implémentées sous la forme de  */
bool ArmeACadenceReglable::estACadenceFixe() const 
{
    return false;
}
bool ArmeACadenceReglable::estACadenceReglable() const
{
    return true;
}

Pour le reste, effectivement, lorsqu'un objet de type dérivé se fait passer pour un objet de type de base, on ne peut accéder qu'aux fonctions et méthodes... déclarées pour le type de base.

Mais, maintenant, nous disposons de tout ce qu'il faut pour permettre à "ce qui va gérer nos armes" d'accepter (ou non) de changer la cadence de tir...

L'interface graphique pourra par exemple déjà désactiver le bouton de sélection si on a affaire à une arme à cadence de tir fixe, sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(perso.armeCourante()->estACadenceReglable())
    selecteur->activate();
else
    selecteur->desactivate();

et, quand il s'agira effectivement de sélectionner une cadence de tire, cela pourra se faire sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
if(perso.armeCourente()->estACadenceReglable())
{
    /* nous savons que nous avons affaire à une arme de type 
     * ArmeACadenceReglable... nous pouvons donc la convertir sans crainte
     */
    ArmeACadenceReglable* temp = static_cast<ArmeACadenceReglable*>
                                 (perso.armeCourente());
    temp->changeCadence();
}

Tu l'aura compris, la variable larme est un pointeur sur l'arme active que ton personnage a en main et la fonction perso.armeCouretente() renvoie un pointeur sur l'arme courante du perso

Cette solution pourrait être améliorée, par exemple en utilisant le design pattern "decorateur" pour toutes les particularités similaires au fait de pouvoir sélectionner la cadence de tir

[SofEvans]

Oula, j'ai de gros progrès a faire en C++.

Merci pour ta réponse (j'ai dû la relire deux fois avant de capter quelque chose), je vais potasser le lien que tu m'as filer.

[koala01]

Oula, j'ai de gros progrès a faire en C++.

Merci pour ta réponse (j'ai dû la relire deux fois avant de capter quelque chose), je vais potasser le lien que tu m'as filer.

En fait, une grosse partie de ma réponse tient plus de la résolution de problèmes de conception que de problèmes propres au C++...

Mais si elle éveille en toi des interrogations, n'hésite pas à nous en faire part, car la programmation a toujours été autre chose que de "vomir" des lignes de code

[SofEvans]

salut,

Alors voila, j'ai commencé a lire les tutoriel en C++ mais comment dire ... malgré le fait qu'il soit très complet, ils sont aussi très compliquer pour mon niveau .
Je bloque sur la notion de méthode virtuelle, méthode pure.
Je comprend mal quand est-ce qu'on les emploi, pourquoi les emploi t'on a la place des méthode normal et quelles sont leur effets.
Je sais que pour vous, la définition et les exemple du tuto sont aussi limpide que de l'eau de roche mais pour moi, c'est plutôt l'eau du port que je vois ....

Bref, si une âme charitable voulais bien prendre le temps de m'expliquer tout ça, j'en serai très reconnaissant.

Merci beaucoup

[koala01]

Nous allons donc commencer par le début...

L'un des avantages apportés par le paradigme orienté objet est la possibilité de créer une relation forte entre deux types qui s'appelle "l'héritage".

Cet héritage représente une relation "EST-UN" (is-a), au sens sémantique du terme.

C'est le genre de relation qui pourrait exister entre une classe "chien" ou "chat" et une classe "animal" ou entre une classe "cercle", "triangle", "rectangle" ou "carré" et une classe "forme", parce que, sémantiquement, un chat ou un chien est un animal et un cercle, un triangle, un carré ou un rectangle sont des formes géométriques.

L'idée est que, comme le cercle ou le rectangle (ou l'une des autres... formes pré-citées) sont des... formes géométriques, nous pouvons les faire passer pour... des formes géométriques, parce qu'il est possible de trouver un comportement "commun" (dans le sens du message recu ou envoyé par la classe) comme "tracer()"(pour les formes géométrique), "manger()", "dormir()"(pour les animaux)...

Si tu souhaite généraliser ce fait, les classes cercle, rectangle, carré, triangle, chat et chien seront appelées "classe dérivées" parce qu'elles... dérivent d'une classe "mère", "parente" ou "de base" qui sont, dans les exemples, les classes "forme" et "animal".

Le fait est que le chat ne dort ou ne mange pas forcément de la même manière que le chien, et encore moins de la même manière qu'une raie manta, qu'un dauphin ou qu'un éléphant, qui sont pourtant tous des animaux.

Transposé aux formes géométriques, la manière de tracer un cercle est différente de celle à utiliser pour tracer un triangle, un rectangle ou un carré (et encore différente de celle de tracer un dodecagone, qui est pourtant aussi une forme géométrique )

Quand on crée ces classes, il faut donc pouvoir prévenir le compilateur que

Attention, ce qui sera effectué pour fournir le comportement dépendra du type réel de l'objet et peut ou doit être redéfini pour chaque type particulier

La manière d'en prévenir le compilateur est de déclarer la fonction virtuelle (avec le mot clé virtual)

Grace à ce mot clé, lorsque le compilateur sera en mesure de se dire "tiens, on me demande d'appeler la méthode (tracer(), manger() ou dormir()), mais je dois aller vérifier que cela ne représente pas un comportement propre au type réel de l'objet pour lequel on invoque ce comportement" (je te fais grâce des détails ardus de la manière dont il s'y prend )

Mais nous sommes confrontés à un dernier problème (du moins, dans le cadre de ces explications) : Au niveau de la classe forme, nous n'avons strictement aucune information qui nous permettrait de tracer une forme géométrique

Nous sommes donc dans l'impossibilité d'implémenter le comportement tracer() pour la classe forme (tout comme nous sommes dans l'impossibilité d'implémenter les différents comportements de la classe animal )

Or, le compilateur a horreur du vide... Du coup, si nous ne disons rien de plus au compilateur (à l'éditeur de liens, en fait), il se plaindra de ne pas trouver l'implémentation (ce qui doit être fait par) de ces comportements...

Il nous faut donc un moyen de signaler au compilateur quelque chose qui pourrait se dire sous une forme proche de

Attention, je ne dispose pas des informations qui me permettraient de t'indiquer quoi faire, donc je ne le fais pas... Tu devra vérifier pour les types dérivés si je suis en mesure de te dire quoi faire.

Ce moyen nous est donné par la possibilité de déclarer une fonction virtuelle pure, en rajoutant simplement un "=0" avant le point-virgule qui termine la déclaration de la fonction.

Cela aura pour résultat de rendre la classe abstraite, c'est à dire une classe qui ne peut pas être instanciée par elle-même: on ne peut pas créer une instance (une variable du type) de cette classe directement.

En effet, le compilateur a horreur du vide, hors, une classe qui contient ne serait-ce qu'une fonction virtuelle pure n'est... pas complète... Et il est programmé pour refuser de créer une variable de ce genre de classe.

Par contre, une fois que toutes les fonctions virtuelles pures ont été redéfinies pour une classe dérivée, nous pouvons sans problème demander la création d'une variable du type dérivé et... la faire passer pour le type de la classe abstraite.

Cela te parait il un peu plus clair, maintenant

[SofEvans]

J'ai beaucoup mieux compris tout ce joyeux bazar ( J'ai quand même fait appel a wiki car paradigme ... J'ai appris un mot ce soir ).

Il y a juste un truc qui me gêne :

Grâce à ce mot clé, lorsque le compilateur sera en mesure de se dire "tiens, on me demande d'appeler la méthode (tracer(), manger() ou dormir()), mais je dois aller vérifier que cela ne représente pas un comportement propre au type réel de l'objet pour lequel on invoque ce comportement" (je te fais grâce des détails ardus de la manière dont il s'y prend )

Ce serait pas plutôt :
je dois aller vérifier que cela représente un comportement propre au type réel de l'objet pour lequel on invoque ce comportement.


Du coup, j'ai vraiment compris pourquoi tu me conseillé les méthodes virtuelle.

Dans un de tes précédent post, dans un de tes codes-exemple, j'ai trouvé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        void changeCadence()
        {
            tirRapide ^= tirRapide;
        }

Le ^ est-il une faute de frappe ou est-ce important ( Je ne connais pas du tout ce symbole en C++ )

J'ai compris la démarche décrite dans ta première réponse, il me manque plus que la pratique afin de comprendre intégralement tes code qui reste pour le moment un peu mystérieux.

Un grand merci a toi koala01, je renomme mon titre afin que quiconque se pose des questions sur les méthode virtuelle puissent trouvé ton exemple très clair.
Bonne soirée a tous !!!

[koala01]

J'ai beaucoup mieux compris tout ce joyeux bazar ( J'ai quand même fait appel a wiki car paradigme ... J'ai appris un mot ce soir ).

Ca sert aussi à ca un forum

Il y a juste un truc qui me gêne :
<sniped quote>


Ce serait pas plutôt :
je dois aller vérifier que cela représente un comportement propre au type réel de l'objet pour lequel on invoque ce comportement.

En fait, ce serait plutôt "si je ne doit pas adapter le comportement au type réel", car, dans certains cas, le comportement doit être adapté au type réel, mais, dans d'autres, il ne doit être adapté que pour certaines classes dérivées, tout en étant implémenté dans la classe de base et cohérent pour d'autres classes dérivées : ce n'est pas *forcément* parce qu'une fonction est déclarée virtuelle dans une classe de base qu'elle devra forcément être redéfinie pour *toutes* les classes dérivées.

Elle peut très bien etre définie dans la classe de base avec un comportement qui reste cohérent avec l'une ou l'autre des classes dérivées

Dans un de tes précédent post, dans un de tes codes-exemple, j'ai trouvé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        void changeCadence()
        {
            tirRapide ^= tirRapide;
        }

Le ^ est-il une faute de frappe ou est-ce important ( Je ne connais pas du tout ce symbole en C++ )

Ce n'est pas du tout une faute de frappe... Le symbole ^ représente le OU exclusif.

Il s'agit d'un opérateur travaillant au niveau des bits des données qui, quand on compare deux bits, donnera vrai uniquement si l'un seul des deux est à vrai, avec la table de vérité suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  A  |  B  | A^B |
faux |faux |faux |
faux |vrai |vrai |
vrai |faux |vrai |
vrai |vrai |faux |

Lorsqu'il est utilisé en conjonction avec le signe égal, (sous la forme de var^= var) cela signifie que var (selon l'exemple) doit prendre... l'inverse de sa valeur de départ.

Cela signifie que, si var est un booléen et que sa valeur de départ est à false, sa valeur passe à true et réciproquement

J'ai compris la démarche décrite dans ta première réponse, il me manque plus que la pratique afin de comprendre intégralement tes code qui reste pour le moment un peu mystérieux.

J'ai toujours estimé que l'on a beaucoup plus facile à utiliser les choses que l'on comprend...

Cela m'obligre régulièrement à écrire un roman pour permettre à la personne qui pose la question de se faire au moins une idée précise, mais, il est vrai que dans d'autres circonstances, il reste nécessaire de partir de l'idée que certains concepts sont connu

Un grand merci a toi koala01, je renomme mon titre afin que quiconque se pose des questions sur les méthode virtuelle puissent trouvé ton exemple très clair.
Bonne soirée a tous !!!

Excellente initiative

[Médinoc]

En fait, dans l'état actuel, la ligne de code que tu as citée est une erreur.
A ^= A possède le même effet que A = 0.

La bonne opération aurait dû être tirRapide ^= 1.

[koala01]

En fait, dans l'état actuel, la ligne de code que tu as cité est une erreur.
A ^= A possède le même effet que A = 0.

La bonne opération aurait dû être tirRapide ^= 1.

Ouppss.. en effet, au temps pour moi...

Je file corriger cette faute impardonnable dans le post d'origine

[SofEvans]

Bonjour,

Merci de ces précisions, je connaissait pas du tout l'operateur ^.
Il faut que je revois toutes les manipumations bit par bit car comme je n'en utilise jamais, je m'en souviens mal.

J'ai un probleme, je n'arrive pas à renommer le titre qui apparait dans la FAC. Je croyais que c'était possible, non ? Comment on fait s'il vous plait