Discussion :

[fregolo52]

Bonjour,

J'ai l'impression de poser une question bateau, mais je dois chercher comme un pied vu que je ne trouve pas grand chose.

Je voudrais m'assurer que j'utilise la bonne méthode.

J'ai une classe de test (Test) qui a comme membre la classe mère (Mere), dans une méthode, j'ai :

Code :

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

1
2
3
4
5
6
7
void Test::Init(int i)
{
  if (i == 1)
    mere = new Fille1;
  else
    mere = new Fille2;
}

Plus loin j'ai besoin d'une méthode de Fille1 qui n'existe pas dans Fille2.
Pour m'assurer que c'est la bonne classe :

Code :

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

Fille1* fille =  dynamic_cast<Fille1*>(mere);

Donc, si c'est Fille2, fille sera nulle.

C'est bien ça ? Y a-t-il une autre méthode (plus sûre) ?

Merci.

[Bousk]

Bonjour,

l'héritage c'est une relation class Fille : public (protected/private) Mere.
Dans ton cas tu as composé Mere dans Test.

Pour ton 2° cas et la méthode, plusieurs possibilités
- celle que tu décris
- une interface commune dans la classe Mere et laisser faire le polymorphisme (virtual, ...)
- sûrement d'autres plus ou moins farfelues

[cob59]

Tu peux déclarer ta méthode en virtuelle pure dans Mere, l'implémenter dans Fille1 et laisser Fille2 avec une implémentation vide (ou déclenchant une exception). Du coup ton objet mere est polymorphe, et mere.tamethode() génère le bon comportement quoiqu'il arrive, sans devoir passer par dynamic_cast.

[koala01]

Salut,

De manière générale, la nécessité de "downcaster" un objet en un objet du type de la classe fille met en évidence un problème de conception à la base...

Cela peut etre du à trois causes différentes :

1. Soit, tu as choisi de recourir à l'héritage alors qu'il n'y avait pas lieu de le faire (il faut vraiment veiller à respecter le LSP (le principe de substitution de Liskov, si tu es allergique aux abréviations ) chaque fois que tu décides de recourir à l'héritage
2. Soit, tu es remonté "trop haut" dans ta hiérarchie (dont on considère que LSP est respecté pour tous les types envisagés) au niveau du type d'objets que tu maintiens dans ta collection
3. Soit tu essayes de donner à un type en particulier une responsabilité qu'il ne devrait pas avoir et qui devrait, dés lors être déléguée à un nouveau type particulier

Le premier cas est une pure décision de conception : il ne faut pas envisager l'héritage public uniquement parce que l'on se rend compte que deux classes présentent une interface commune...

L'héritage public est la relation la plus forte qui puisse exister entre deux classes, dans le sens où (c'est ce que nous indique LSP ) un objet dont le type est une classe qui dérive d'une autre doit pouvoir passer pour être un objet de la classe de base sans que cela ne nuise au bon déroulement du programme (modulo les adaptations éventuelles de comportement).

On dit souvent que l'héritage est une relation EST-UN, mais c'est vraiment à prendre du point de vue sémantique du terme dans le sens où, si tu ne peux décemment pas estimer qu'un objet du type dérivé EST-UN objet du type de la classe de base, c'est qu'il est sans doute préférable d'envisager une relation moins forte (comme l'agrégation, par exemple)

Le deuxième cas dépend fortement de ta conception générale, mais, en gros, s'il faut que tu fasses le distingo entre un type dérivé particulier et un autre, peut etre devrais tu envisager la solution qui consiste à garder à jour une collection de pointeurs sur ce type particulier, de manière à te permettre de les traiter par lot

Le troisième cas est, malheureusement, très fréquent, et part aussi d'un problème de conception, du essentiellement au fait que la responsabilité de la classe qui va utiliser les objets de type dérivés n'est pas clairement définie, ou que la "granularité" de la responsabilité de cette classe n'est pas adaptée au cas auquel tu es confronté...

Dans ce cas, tu pourras surement t'en sortir en mettant en place le "double dispatch" qui permettra à une classe d'effectuer un traitement particulier en fonction du type réel de l'objet à traiter.

L'exemple "générique" de mise en place du double dispatch est le patron de conception connu sous le terme de "visiteur", dont tu pourrais peut etre t'inspirer

[fregolo52]

Bonjour

merci pour vos réponses.

koala01, avec ta description, je me rends mieux compte (même si j'avais des soupçons) que je fais un truc dégueulasse.

En fait, le downcast est lié au fait que je ne veux pas modifier la Mere parce qu'elle a beaucoup trop de filles. C'est un outil de config pour des dixièmes d'applis (donc autant de filles). Je ne bosse que sur une des filles. (hors contexte ça pourraît être louche )

je vais essayer de réfléchir pour faire autrement.

[koala01]

Bonjour

merci pour vos réponses.

koala01, avec ta description, je me rends mieux compte (même si j'avais des soupçons) que je fais un truc dégueulasse.

En fait, le downcast est lié au fait que je ne veux pas modifier la Mere parce qu'elle a beaucoup trop de filles. C'est un outil de config pour des dixièmes d'applis (donc autant de filles). Je ne bosse que sur une des filles. (hors contexte ça pourraît être louche )

je vais essayer de réfléchir pour faire autrement.

Dans ce cas, je présume que chaque application a une classe fille qui lui est propre et que tu n'utiliseras jamais une classe fille utilisée par une application différente...

La meilleure solution est donc, au sein de l'application, de travailler directement avec le type réel de ton outil de configuration

Ceci dit, le downcast peut malgré tout etre envisagé si ( et seulement si ) tu peux respecter malgré tout ce que l'on appelle l'OCP (le principe "ouvert fermé"), qui dit qu'un code doit etre ouvert aux évolutions et fermé aux modifications.

Dans le cas présent, le fait que, quoi qu'il arrive, tu ne devra sans doute jamais aller rajouter un type de la classe dérivé lors de ton downcast semble plaider en faveur d'une exception à la règle

Mais cette exception doit alors être mise en place de manière cohérente, et il faut impérativement éviter que le downcast ne soit utilisé "partout dans le code"...

L'idéal étant alors une fonction qui appellera static_cast ( après tout, on est sur du type que l'on veut récupérer ) et qui elle sera appelée dans le code