Discussion :

[hbenji]

Bonjour,

Je vais expliquer mon problème par un exemple.

J'ai 4 class, une class mère, une class fils1, une class fils2 et une class3

les class fils héritent de class mère.

Dans mon main j'ai un vecteur (vecteur <mere*>), donc lors d'un nouveau class1, class2 ou class3 je le place dans ce vecteur.

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

Merci pour votre aide.

[poukill]

Non, tu peux pas savoir.
Une bonne question, c'est "pourquoi tu veux savoir ?"
Sinon une solution qui marche c'est un truc du genre :

Code :

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

1
2
3
4
class Base
{
     virtual const std::string GetTypeName const () = 0;
};

Tu fais hériter tes classes de Base, et dans tes classes tu redéfinis la méthode GetTypeName :

Code :

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

1
2
3
4
class Mere : public Base
{
     virtual const std::string GetTypeName const () {return "Mere";}
};

Tu peux faire une macro pour automatiser ça...

[ternel]

Mias surtout, répond d'abord à la question importante: Pourquoi en ai-je besoin?
C'est à dire:
Pourquoi mettrai-je des choses différentes dans le même tas, si c'est pour les traiter différemment?
Il y a deux façons de réfléchir à ce problème:

• N'aurai-je pas du faire plusieurs tas? c'est à dire utiliser plusieurs vecteurs
• Ne puis-je pas faire en sorte d'agir de la même façon? utiliser l'héritage et la virtualité permet d'avoir des réactions différentes à une même stimulation

[Iradrille]

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

Bonjour,

Tu peux récupérer le type à l'aide du pattern visiteur, ça donne quelque chose du genre :

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
struct Visitor {
	void operator()(Class1& c) { /* code spécifique à Class1 */ }
	void operator()(Class2& c) { /* code spécifique à Class2 */ }
};
 
struct Mere {
	...	
	virtual void accept(V& visitor) = 0;
}
 
struct Class1 {
	...
	virtual void accept(V& visitor) { v(*this); }
}
 
struct Class2 {
	...
	virtual void accept(V& visitor) { v(*this); }
}
 
std::vector<Mere*> vec;
...
Visitor v;
for(auto ptr: vec) {
	ptr->accept(v);
}

Pourquoi mettrai-je des choses différentes dans le même tas, si c'est pour les traiter différemment?

Il arrive de devoir faire une opération a() sur tous les éléments, et une opération b() seulement sur un seul type par exemple. Mais effectivement, la question est à se poser.

[oodini]

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

Il y a la solution du dynamic_cast, qui n'est généralement pas des plus heureuses.

[poukill]

Il y a la solution du dynamic_cast, qui n'est généralement pas des plus heureuses.

C'est vrai c'est pas toujours heureux mais il y a parfois des cas où c'est une bonne solution.

[Bousk]

Il arrive de devoir faire une opération a() sur tous les éléments, et une opération b() seulement sur un seul type par exemple. Mais effectivement, la question est à se poser.

Dans ce cas, pourquoi de l'héritage ?
Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu non non avenu.

[oodini]

Je suis tout à fait en désaccord.

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

[r0d]

Dans ce cas, pourquoi de l'héritage ?
Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu non non avenu.

Je plussoie.
C'est décidément un problème à la mode ces temps-ci.
Pourquoi vouloir faire une hiérarchie de classe si chaque classe a un protocole différent? ça ne fait que rajouter des complications et ça n'apporte rien.
C'est comme les templates; parfois je vois du code où on voit clairement que le développeur à voulu absolument utiliser des templates alors que ça n'apporte que, dans le meilleur des cas, de la complexité au code.

[Bousk]

Je suis tout à fait en désaccord.

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

Si la classe Mere définit une interface doStuff(), la classe fille pourra faire doStuff(), voire doStuff2(), doStuff() de la fille pourra même n'être qu'une indirection vers son propre doStuff2() mais à aucun moment on ne doit avoir besoin d'appeler doStuff2() sur une Mere, et à raison : ça n'existe pas.

[r0d]

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

Pas si cette fonction est publique, en effet.
Et c'est une conception de la poo qui est très partagée dans la communauté et ce principe porte même un nom, le principe de substitution de Liskov.

Respecter ce principe reviens à respecter le principe est-un de l'héritage tel qu'il a été conçu en c++, et il apporte beaucoup d'avantages concrets dans le développement. Je ne développerai pas ici, mais effectue une recherche sur LSP et tu trouveras des informations beaucoup plus pertinentes que je ne serais capable de produire.

[koala01]

Salut,

De manière générale, tu peux (comprends: il est tout à fait légal de le faire ) envisager de fournir une méthode qui permet de récupérer le type réel de ton pointeur et de travailler à coup de dynamic_cast.

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
enum ClassType
{
    fils1,
    fils2,
    fils3
};
class Mere
{
    public:
        virtual ClassType type() const = 0;
};
class Fils1 : public Mere
{
    public:
        virtual ClassType type() const {return fils1;}
};
class Fils2 : public Mere
{
    public:
        virtual ClassType type() const {return fils2;}
};
class Fils3 : public Mere
{
    public:
        virtual ClassType type() const {return fils3;}
};
 
int main()
{
    std::vector<Mere*> tab;
    /* ... */
    for(auto it : tab)
    {
        switch(it->type())
        {
            case fils1:
                Fils1 * temp= dynamic_cast<Fils1*>(it);
                /* ... */
                break;
            case fils1:
                Fils2 * temp= dynamic_cast<Fils2*>(it);
                /* ... */
                break;
            case fils1:
                Fils3 * temp= dynamic_cast<Fils3*>(it);
                /* ... */
                break;
        }
    }
}

Mais je te déconseille très fortement et avec la plus grand insistance de faire de la sorte

En effet, si tu choisis cette option, tu vas très rapidement te retrouver dans une situation dans laquelle tu passeras ton temps à tester le type réel de tes objets (ou plutôt de tes pointeurs ou de tes références) avant de les transtyper afin de pouvoir les utiliser.

Cela va mener à une complexification systématique et largement inutile de ton code et cela va présenter un inconvénient majeur:

Si tu décides, un jour, de rajouter une classe dérivée (et les raisons pour le faire sont nombreuses, la question n'est donc pas de savoir SI tu voudras le faire, mais bien QUAND tu voudras le faire ), tu devras reprendre systématiquement tout ton code pour prendre cette nouvelle classe en compte

L'idéal est donc de se baser sur le principe du double dispatch:

L'idée est de se dire que les pointeurs connaissent leur type réel.

Il est donc possible d'envisager un comportement que l'on appellera au départ de "tout objet passant pour être du type de base" qui s'adaptera au type réel de l'objet.

Le principe du visiteur se base sur un principe similaire

[oodini]

Si c'est pour être utilisé comme ça, aucun intérêt à utiliser un dynamic_cast au lien d'un static_cast, moins coûteux.

[koala01]

Si c'est pour être utilisé comme ça, aucun intérêt à utiliser un dynamic_cast au lien d'un static_cast, moins coûteux.

En effet, mais, comme je déconseille fortement de recourir à cette technique...

[hbenji]

Quel débat, déjà merci pour votre aide

enfaite ceux que je veux faire c'est que: (en reprenant mon exemple)

1) dans le main c'est d'avoir un seul vecteur pour toutes les class ou si ce n'est pas possible avoir un vecteur pour chaque class, je ne sais pas quel est le meilleur choix.

2) la class mère possède un vecteur d'objets de type A par exemple, donc les 3 class fils héritent de ce vecteur et le problème c'est que A possède un fils B et C mais fils1 et fils2 ne peuvent pas avoir d'objet de type B dans leur vecteur alors que fils3 peut en avoir, c'est surtout pour ça que je voulais savoir si on peut connaitre le type d'un objet s'il c'est de type B ou de type C.

Merci encore.

[JolyLoic]

Respecter ce principe reviens à respecter le principe est-un de l'héritage tel qu'il a été conçu en c++, et il apporte beaucoup d'avantages concrets dans le développement. Je ne développerai pas ici, mais effectue une recherche sur LSP et tu trouveras des informations beaucoup plus pertinentes que je ne serais capable de produire.

Le principe de substitution de Liskov dit juste qu'on doit concevoir nos classes de telle manière que partout où une classe de base est attendue, on puisse la substituer par une classe dérivée, est que tout se passe bien. Il n'interdit pas à une classe dérivée de proposer des services supplémentaires.

[JolyLoic]

Salut,

De manière générale, tu peux (comprends: il est tout à fait légal de le faire ) envisager de fournir une méthode qui permet de récupérer le type réel de ton pointeur et de travailler à coup de dynamic_cast.

Franchement, je déconseille encore plus l'utilisation d'une telle méthode que l'utilisation du dynamic_cast brut de fonderie.

Pourquoi ? Parce que dans la quasi-totalité des cas, une telle méthode marche mal avec plusieurs niveaux d'héritage, là où dynamic_cast marche (C dérive de B dérive de A, on peut dynamic_caster un A* en B* si l'objet pointé est de type C). En plus, je ne vois aucun apport de cette méthode (à part le risque de fautes de frappe dans les chaînes de caractère non repérées par le compilateur, et les performances moins bonnes).

[koala01]

Franchement, je déconseille encore plus l'utilisation d'une telle méthode que l'utilisation du dynamic_cast brut de fonderie.

Pourquoi ? Parce que dans la quasi-totalité des cas, une telle méthode marche mal avec plusieurs niveaux d'héritage, là où dynamic_cast marche (C dérive de B dérive de A, on peut dynamic_caster un A* en B* si l'objet pointé est de type C). En plus, je ne vois aucun apport de cette méthode (à part le risque de fautes de frappe dans les chaînes de caractère non repérées par le compilateur, et les performances moins bonnes).

Oh, tu as coupé ma citation beaucoup trop tot

Je dis qu'il est légal de le faire, que c'est autorisé par le langage, mais je dis aussi qu'il est très largement recommandé d'éviter de le faire, non

[JolyLoic]

Disons qu'il y a deux aspects :
1 - Le fait de tester le type réel d'un objet, quel que soit la manière
2 - La manière de tester ça.

Pour moi, le reste de ta citation s'attachait à dire que le point 1 était mauvais. Et sur ce point, je suis à 100% avec toi.

Mon intervention avait pour but de dire que si, on voulait passer outre, la manière dont tu proposais de le faire dans ton exemple n'était pas la meilleure. Je préfère largement (bien que je n'aime quand même pas) du code qui ressemblerait à :

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
for(auto it : tab)
    {
        Fils1 * fils1= dynamic_cast<Fils1*>(it);
        if (fils1 != nullptr)
        {
                /* ... */
        }
        else
        {
            Fils2 * fils2= dynamic_cast<Fils2*>(it);
            if (fils2 != nullptr)
            {
                /* ... */
            }
        }
    }

[oodini]

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

Disons que j'ai une classe mère Véhicule, qui a deux classes filles Voiture et Vélo.
En gros, tu m'interdis de créer le service démarrer() pour la classe Voiture, parce qu'elle n'est pas factorisable dans la classe Véhicule (on ne démarre pas un vélo).
Je suis supposer la pousser, ma voiture ?

Si la classe Mere définit une interface doStuff(), la classe fille pourra faire doStuff(), voire doStuff2(), doStuff() de la fille pourra même n'être qu'une indirection vers son propre doStuff2() mais à aucun moment on ne doit avoir besoin d'appeler doStuff2() sur une Mere, et à raison : ça n'existe pas.

Je ne vois pas en quoi ce que tu dis interdit de définir une nouvelle méthode sur la classe file.