Discussion :

[Pamputt]

Bonjour,
disons que j'ai une classe A dont dérivent les classes B et C

B a une méthode MethodeB tandis que C a une méthode MethodeC.

Je déclare une variable du type A

Code :

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

A *MonObjet

Sous certaines conditions, A est en fait soit un objet B soit un objet C.

A un moment dans mon code, je fais donc

Code :

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

1
2
3
4
if(condition == true) 
MonObjet = new B();
else
MonObjet = new C()

La question devient alors de savoir comment faire en sorte que MonObjet soit capable d'utiliser MethodeB ou MethodeC suivant qu'il soit du type B ou C respectivement. J'imagine que c'est une question basique de c++ mais j'avoue que je sèche un peu.

Merci d'avance.

[Médinoc]

Tu fais une MethodeA() virtuelle (voire virtuelle pure) dans la classe A,
que tu redéfinis dans chacune des classes B et C, pour lui faire appeler MethodeB() ou MethodeC() respectivement.

[Pamputt]

Hmmm, en fait je ne peux pas faire ça car les classes A, B et C appartiennent à un framework.
Je pensais plutôt à un cast de MonObjet (de type A au début) en type B ou C, ou quelque chose dans cet esprit.

[Médinoc]

Hmmm, en fait je ne peux pas faire ça car les classes A, B et C appartiennent à un framework.

Explique ce que tu veux dire par là. En gros, aucune de ces trois classes n'est sous ton contrôle?
Au pire, tu peux toujours rajouter une couche d'abstraction, avec ta propre hiérarchie de classes qui appellent les trois autres...

Je pensais plutôt à un cast de MonObjet (de type A au début) en type B ou C, ou quelque chose dans cet esprit.

C'est faisable, mais généralement considéré comme un symptôme d'une mauvaise conception.

[Pamputt]

Oui en gros, les classes A, B et C ne sont pas sous mon contrôle.

Je ne connais pas la méthode de la couche d'abstraction. Comment ça marche ?

Bon sinon, la méthode du "cast" me tente bien même si ce n'est pas très propre car c'est juste un projet dans un coin.

[bacelar]

Donnez-nous les vrais noms des classes, si les concepteurs de ces classes sont pas trop tebé, on saura comment elles fonctionnent entre elle et voir si vous êtes complètement à côté de la plaque.

[Pamputt]

J'ai les classes G4ParticleGun et G4GeneralParticleSource qui héritent de la classe G4VPrimaryGenerator. Ce qui se passe c'est que j'ai un objet qui est soit un G4ParticleGun soit un G4GeneralParticleSource. Je déclare donc mon objet comme un G4VPrimaryGenerator mais si je le construis avec

Code :

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

G4VPrimaryGenerator *MonObjet = new G4ParticleGun()

Ensuite je voudrais pouvoir appeler des méthodes de G4ParticleGun tel que « SetParticleEnergy ». Mais si je fais

Code :

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

MonObjet->SetParticleEnergy(0);

mon compilateur me dit que SetParticleEnergy n'appartient pas à G4VPrimaryGenerator (ce qui est effectivement le cas).

[bacelar]

Pourquoi "MonObjet" est un "G4VPrimaryGenerator*" ???

Vous savez que c'est un "G4ParticleGun*" donc faites en une variable de CE type.

Si vous avez des listes de des machins "G4VPrimaryGenerator", et que vous avez besoin d'appeler des méthodes spécifiques à "G4ParticleGun" ou "G4GeneralParticleSource", utilisez simplement 2 listes différentes, une de G4ParticleGun et une de G4GeneralParticleSource;


P.S.: Pensez à remplacer TRÈS RAPIDEMENT ces pointeurs nus par des pointeurs intelligents.

Code :

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

1
2
unique_ptr<G4ParticleGun> MonObjet = make_unique<G4ParticleGun>();
MonObjet->SetParticleEnergy(0);

[Pamputt]

En fait, je voudrais que l'utilisateur de mon code (moi) puisse choisir au lancement du programme si on utilise un G4ParticleGun ou un G4GeneralParticleSource. Ces deux classes ont une méthode virtuelle « GeneratePrimaryVertex » qui est utilisée par le cœur du logiciel. Du coup, je définit un objet générique (G4VPrimaryGenerator) et je décide après coup si c'est un G4ParticleGun ou un G4GénéralParticleSource suivant le choix de l'utilisateur.

P.S.: Pensez à remplacer TRÈS RAPIDEMENT ces pointeurs nus par des pointeurs intelligents.

Code :

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

1
2
unique_ptr<G4ParticleGun> MonObjet = make_unique<G4ParticleGun>();
MonObjet->SetParticleEnergy(0);

Sinon en passant, c'est quoi la différence entre

Code :

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

A *MonObjet = new A()

et

Code :

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

unique_ptr<A> MonObjet = make_unique<A>()

[bacelar]

Ces deux classes ont une méthode virtuelle « GeneratePrimaryVertex » qui est utilisée par le cœur du logiciel.

Vous n'avez donc pas besoin de les distinguer ailleurs qu'à leur création.
Il faut donc juste utiliser un Pattern de création un peu plus sophistiqué que juste un "new" (qui ne devrait JAMAIS apparaître dans du C++11 "standard").

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
 
 
unique_ptr<G4ParticleGun> CreateG4ParticleGun()
{
   unique_ptr<G4ParticleGun> ret = std::make_unique<G4ParticleGun>();
...
   ret ->SetParticleEnergy(0);
...
   return ret;
}
...
unique_ptr<G4GeneralParticleSource> CreateG4GeneralParticleSource()
{
...
}
...
 
unique_ptr<G4VPrimaryGenerator> MonObjet = choixUtilisateur ? CreateG4ParticleGun() : CreateG4GeneralParticleSource();

Sinon en passant, c'est quoi la différence entre

T'es-tu déjà demandé où allait être appelé de delete correspondant à ton new ?
Moi, avec unique_ptr, je m'en fout.

[Ehonn]

"new" (qui ne devrait JAMAIS apparaître dans du C++11 "standard")

Petite remarque : std::make_unique n'est disponible qu'en C++14
(en C++11, j'ai ma propre fonction make_unique).

[Pamputt]

Vous n'avez donc pas besoin de les distinguer ailleurs qu'à leur création.
Il faut donc juste utiliser un Pattern de création un peu plus sophistiqué que juste un "new" (qui ne devrait JAMAIS apparaître dans du C++11 "standard").

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
 
 
unique_ptr<G4ParticleGun> CreateG4ParticleGun()
{
   unique_ptr<G4ParticleGun> ret = std::make_unique<G4ParticleGun>();
...
   ret ->SetParticleEnergy(0);
...
   return ret;
}
...
unique_ptr<G4GeneralParticleSource> CreateG4GeneralParticleSource()
{
...
}
...
 
unique_ptr<G4VPrimaryGenerator> MonObjet = choixUtilisateur ? CreateG4ParticleGun() : CreateG4GeneralParticleSource();

T'es-tu déjà demandé où allait être appelé de delete correspondant à ton new ?
Moi, avec unique_ptr, je m'en fout.

Hmmm, ok. Cela dit ça ne résoud pas complètement mon problème car avec cette « technique », je ne peux plus retoucher aux attributs de G4ParticleGun une fois que j'ai quitté la fonction CreateG4ParticleGun. Or j'ai effectivement besoin de retoucher à ses attributs car l'énergie de mon objet, par exemple, est amenée à être modifiée.

[Pamputt]

Bon, v oici la méthode que j'ai trouvé. Sûrement que vous n'allez pas aimer mais ça semble faire ce que je veux.
J'ai définit trois variables

Code :

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

1
2
3
G4VPrimaryGenerator* m_primaryGenerator;
G4ParticleGun *m_particleGun;
G4GeneralParticleSource *m_generalParticleSource;

Dans ma classe je fais des trucs du genre

Code :

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

1
2
3
4
if(IsParticleGun)
m_particleGun = new G4ParticleGun()
else
m_generalParticleSource = new G4GeneralParticleSource()

et à chaque fois que je change les attributs de m_particleGun ou de m_generalParticleSource, je fais un

Code :

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

1
2
3
4
5
6
if(IsParticleGun) {
m_primaryGenerator = (G4ParticleGun*)m_particleGun;
} else {
        m_primaryGenerator = (G4GeneralParticleSource*)m_generalParticleSource;
}
    m_primaryGenerator->GeneratePrimaryVertex(anEvent);

[foetus]

Et une petite question:

À quoi te sert ta variable m_primaryGenerator? (Plus général, à quoi te sert d'utiliser l'héritage? )

Parce qu'il faut faire un test pour garnir cette variable et appeler ensuite une méthode virtuelle.

Si tu ne peux pas supprimer ton test, pourquoi ne pas utiliser directement la bonne variable/ appeler directement la bonne méthode spécifique/ encapsuler ce test dans un G4ParticleSource_Handler (<- soyons fou )

[Pamputt]

Euh tu as sûrement raison dans le fond, mais je ne suis pas sûr de tout comprendre. Ma variable m_primaryGenerator ne sert en effet à rien vu que je pourrais tout aussi bien faire

Code :

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

1
2
3
4
5
if(IsParticleGun) {
m_particleGun->GeneratePrimaryVertex(anEvent);
} else {
m_generalParticleSource->GeneratePrimaryVertex(anEvent);
}

à la place de

Code :

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

1
2
3
4
5
6
if(IsParticleGun) {
m_primaryGenerator = (G4ParticleGun*)m_particleGun;
} else {
        m_primaryGenerator = (G4GeneralParticleSource*)m_generalParticleSource;
}
    m_primaryGenerator->GeneratePrimaryVertex(anEvent);

Donc je suis ouvert à vos propositions (c'est le sens de ce sujet).

Est ce que tu peux m'en dire plus sur un éventuel G4ParticleSource_Handler?

[bacelar]

Truffer votre code de "if(IsParticleGun)", est un enfer à maintenir.
Il faut confiner les points de variabilité de votre algorithme dans des structures dédiées, comme le ferait un "G4ParticleSource_Handler", par exemple.

Or j'ai effectivement besoin de retoucher à ses attributs car l'énergie de mon objet, par exemple, est amenée à être modifiée.

Pourquoi ne pas mettre ce mécanisme dans une classe dérivée de "G4ParticleGun" ?
Voir de faire de ce mécanisme un objet complètement disjoint, comme un "EnergieCalculator", en utilisant un DP Startégie.

En clair, votre approche n'est vraiment pas la plus élégante mais avec un peu de réflexion, on trouvera bien plus maintenable.

[koala01]

Salut,

Ce que je te conseillerais, c'est de travailler en trois temps :

Dans un premier temps, tu encapsulerait le générateur de particule dans un "ParticleSourceHandler", sous une forme sans doute proche de

Code :

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

1
2
3
4
5
6
class ParticleSourceHandler{
public:
    bool accept(ParticleVisitor /*const */ &) /*const*/ ; // j'en parle tout de suite ;)
private:
    std::unique_ptr<G4GeneralParticleSource> source_;
};

Dans un deuxième temps, tu crée une fabrique de "source de particules", qui te permette de créer le canon qui t'intéresse, sous une forme proche de celle proposée par pamputt, et qui te permettrait donc d'avoir un constructeur pour ton handler qui prendrait 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
 
/* considérons qu'il existe une énumération reprenant tous les types de générateurs de particules possibles, proche de*/
enum GeneratorType{
source,
canon,
/* d'autres possibles */
};
class ParticleSourceHandler{
public:
    ParticleSourceHandler(GeneratorType type){
        switch(type){
            case source:
                source_.swap(CreateG4GeneralParticleSource());
                break;
            case canon:
               source_.swap(CreateG4ParticleGun());
               break;
           /* idem pour tous les autres types de générateur de particules */
            default:
                assert(!"unknown source type");  
        }
    }
    bool accept(ParticleVisitor /*const */ &) /*const*/ ; // j'en parle tout de suite ;)
private:
    std::unique_ptr<G4GeneralParticleSource> source_;
};

Et, dans un troisième temps, tu crées un visiteur de ton handler, qui expose une fonction surchargée pour chaque type de générateur 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
11
12
13
/* NOTA : on pourrait même envisager de créer une hiérarchie de visiteurs, pour appliquer différents traitements à chaque type de source ;) */
class SourceVisitor{ 
public:
    /*virtual */bool visit(G4ParticleGun /*const*/ &) const{
        /*traitment spécifique au canon */
       return /* échec/résussite */
    }
 
    /*virtual */bool visit(G4GeneralParticleSource /*const*/ &) const{
        /*traitment spécifique au générateur de particule */
       return /* échec/résussite */
    }
};

Ce visiteur te permettra de disposer du double dispatch pour l'implémentation de ta fonction accept, qui prendra dés lors une forme proche 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
 
/* considérons qu'il existe une énumération reprenant tous les types de générateurs de particules possibles, proche de*/
enum GeneratorType{
source,
canon,
/* d'autres possibles */
};
class ParticleSourceHandler{
public:
    ParticleSourceHandler(GeneratorType type){
        switch(type){
            case source:
                source_.swap(CreateG4GeneralParticleSource());
                break;
            case canon:
               source_.swap(CreateG4ParticleGun());
               break;
           /* idem pour tous les autres types de générateur de particules */
            default:
                assert(!"unknown source type");  
        }
    }
    bool accept(ParticleVisitor /*const */ & v) /*const*/ {
        return v.visit(*(source_.get()));
    }
private:
    std::unique_ptr<G4GeneralParticleSource> source_;
};

Et le tour est joué : chaque surcharge de la fonction visit prend en charge un type bien précis de générateur, et peut donc faire appel aux fonctions qui lui sont spécifiques

Cette approche est, finalement, basée sur la fameuse phrase de David Wheeler

All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.
(tout problème en science informatique peut être résolu par un niveau d'indirection supplémentaire, excepté bien sur le problème de trop nombreuses indirections ; translation's mine)

EDIT : Ceci dit, l'idéal, quand ont a été "assez bête" que pour perdre le type réel d'un objet, et qu'on ne le connait que comme "étant du type de base", ca reste toujours de ne manipuler cet objet qu'au travers... des fonctions membres exposées par le type de base (à l'exclusion de toute fonction spécifique au type réel de l'objet).

En outre, je suis particulièrement allergique à l'idée même d'exposer des mutateur (setXXX, setYYY), car c'est souvent le symptôme même que le développeur de la classe a réfléchi à sa fonctionnalité sur base des données qui la composent au lieu d'y réfléchir sur base des services qu'elle est sensée rendre.

Par exemple, il peut effectivement exister plusieurs types de canons à particules. Tous ces canons sont susceptibles de tirer des "charges de particules" (des "obus" ) potentiellement différentes, mais chaque canon est sensé ne tirer qu'un seul type d'obus à un moment donné.

Un canon devrait donc avoir une fonction "shoot", permettant d'obtenir l'obus qu'il vient de tirer (sans autre précision que le fait que c'est un obus), et un fonction "reload", dont une version permettrait de recharger avec le même type d'obus et dont une version surchargée permettrait de... modifier le type d'obus tiré.

Mais, quoi qu'il en soit, chaque la "charge" de chaque obus tiré n'a absolument aucune raison d'être modifiée une fois que l'obus a été tiré, vu qu'elle est sensée être définie (et immuable !!!) pour chaque type d'obus potentiel.

Dés lors, le seul traitement envisageable pour un canon est... d'appeler l'une de ces deux fonctions : shoot et reload, et de récupérer (pour ce qui concerne shoot)... l'obus qui a été tiré, dont toutes les caractéristiques sont clairement définies par le constructeur même de la classe qui représente cette notion