Discussion :

[LinuxUser]

Bonjour,

Si on a les classes suivantes:

Code :

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

1
2
3
class Mere
{...
};

Code :

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

1
2
3
4
class Fille : public Mere
{
  void methodePropreALaFille();
};

Admettons à présent que j'ai une fonction:

Code :

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

void function(Mere& m);

Et que dans le corps de cette fonction j'ai besoin d'appeler la fonction propre à la fille sachant que j'appelle la fontion de cette manière:

Code :

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

1
2
3
...
Fille f = Fille();
function(f);

Dans function():

Code :

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

1
2
3
4
5
void function(Mere& m)
{...
  m.methodePropreALaFille();// comment faire pour réaliser cette appel?
...
}

Dois-je faire un dynamic cast avant d'appeler la méthode ou y a-t-il quelque chose de plus intéligent à faire (et qui necessite surtout pas de cast)?

Merci de votre aide.

[ternel]

Il y a mieux, en effet, mais j'aurai un peu de mal à l'expliquer avec toute la précision nécessaire.

L'idée est d'utiliser la surcharge.

Code :

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

1
2
3
4
5
6
void function(Mere& m) {
    /**/
}
void function(Fille& f) {
    f.methodePropreALaFille();
}

L'autre possibilitée, c'est de passer par une fonction virtuelle, mais ca n'a pas forcément de sens.

En général, ce problème apparait quand tu as en réalité plusieurs filles de mere, et que certaines ont un traitement particulier.
auquel cas, il peut être intéressant d'introduire une classe intermédiaire pour ces filles là.

Code :

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

1
2
3
4
5
6
7
8
9
struct mere {}
struct fille1 : mere {}
struct fille2 : mere {}
struct fille3 : mere {
    void truc();
}
struct fille4 : mere {
    void truc();
}

deviendrait alors:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
struct mere {}
struct fille1 : mere {}
struct fille2 : mere {}
struct trucoidal : mere {
    virtual void truc();
}
struct fille3 : trucoidal {
    void truc();
}
struct fille4 : trucoidal {
    void truc();
}

[LinuxUser]

L'idée est d'utiliser la surcharge.

Code :

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

1
2
3
4
5
6
void function(Mere& m) {
    /**/
}
void function(Fille& f) {
    f.methodePropreALaFille();
}

Justement je souhaite garder uniquement ce prototype : void function(Mere& m)

En général, ce problème apparait quand tu as en réalité plusieurs filles de mere, et que certaines ont un traitement particulier.
auquel cas, il peut être intéressant d'introduire une classe intermédiaire pour ces filles là.

C'est le cas en fait, mais j'ai juste voulu simplifier l'exemple.

Code :

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

1
2
3
4
5
6
7
8
9
struct mere {}
struct fille1 : mere {}
struct fille2 : mere {}
struct fille3 : mere {
    void truc();
}
struct fille4 : mere {
    void truc();
}

deviendrait alors:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
struct mere {}
struct fille1 : mere {}
struct fille2 : mere {}
struct trucoidal : mere {
    virtual void truc();
}
struct fille3 : trucoidal {
    void truc();
}
struct fille4 : trucoidal {
    void truc();
}

Je vois pas trop l'intérêt, j'ai l'impression que le problème est juste déplacé.

[Bousk]

Je vois pas trop l'intérêt, j'ai l'impression que le problème est juste déplacé.

L'intérêt c'est de passer non pas un Mere& mais un Trucoidal& en paramètre.
L'héritage revient à factoriser des comportements et services. Devoir faire appel à une méthode spécifique à un type fille n'est pas du tout normal et montre au moins un gros manque architectural.
Si ta méthode doit faire appel à une méthode de fille
- elle doit prendre un fille en paramètre
--> sinon elle traite comment les cas où c'est pas une fille mais fille2 ?!?
- la méthode de fille n'est pas spécifique à fille mais spécialisée
--> on factorise alors le comportement et service à travers cette méthode

[r0d]

En fait, le problème qui se pose ici est assez courant, et il vient du fait que le protocole (ensemble des fonctions et variables publiques de la classe) de la classe mère est différent de celui de la classe fille. Ça viole le LSP, et donc, ça pose potentiellement tout un tas de problèmes (celui évoqué ici n'en est qu'un parmi bien d'autres).

Donc effectivement, comme toujours, la solution consiste à ajouter un niveau d'indirection. Visiteur est généralement approprié.

Parfois il n'est pas nécessaire de respecter LSP, mais c'est assez rare. Il s'agit de cas où on est sûr que le code qui utilise ces classes ne déclarera jamais un objet de type Mere, et donc qu'il n'utilisera que les classes héritées. Mais en dehors de ce cas rare, respecter LSP permet un confort non négligeable dans le cycle de développement. Confort dont on ne prend pas forcément conscience, puisque les problèmes ne posent pas... mais je m'égare...

[LinuxUser]

Dans mon cas, je ne cherche pas à respecter LSP, car les classe Filles sont des implémentations différentes de la classe mère (qui n'est jamais instanciée et ne le sera jamais).

En fait, mon idée c'est plutôt:
* j'ai une classe mère abstraite : Mere
* j'ai des classes filles qui implémentent Mere: Fille1, Fille2, Fille3
* j'ai des fonctions qui utilisent Fille1 ou Fille2 ou Fille3 quasiment de la même manière, et donc pour factoriser je fait:

Code :

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

1
2
3
void function(Mere& m)
{...// code polymorphe qui fonctionne que ce soit Fille1, 2 ou 3
}

Sauf que dans cette fonction je voudrait faire un seul appel de méthode spécifique à Fille2 par exemple:

Code :

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

1
2
3
4
void function(Mere& m)
{...// tout le code idem que précédemment
m.methodeDeFille2();
}

Je trouverais dommage de devoir dupliquer du code à cause d'une seule méthode:

Code :

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

1
2
3
void function(Fille1& f);
void function(Fille2& f);
void function(Fille3& f);

Et donc avoir 3 fonctions avec 99% de code identique.

[poukill]

Code :

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

1
2
3
4
5
void function(Mere& m)
{...
  m.methodePropreALaFille();// comment faire pour réaliser cette appel?
...
}

Ah, un grand classique !
Plusieurs techniques :

• Le pattern template method : une fonction membre virtuelle dans la classe mère qui appelle une ou plusieurs fonctions virtuelles à définir dans les classes filles. C'est très utilisé pour modifier des comportements d'algos. Par contre, ça ne marche que si les comportements sont factorisables.
• Le pattern visiteur : l'arme absolue pour ces problèmes de downcasting. Ça permet de pouvoir donner une implémentation différente pour chaque classe fille.

Iil y a déjà eu pas mal de question là dessus, une petite recherche sur le forum avec le mot clé downcasting devrait de donner pas mal d'infos (je me souviens avoir posé moi-même des questions là dessus il fut un temps).

[LinuxUser]

• Le pattern template method : une fonction membre virtuelle dans la classe mère qui appelle une ou plusieurs fonctions virtuelles à définir dans les classes filles. C'est très utilisé pour modifier des comportements d'algos. Par contre, ça ne marche que si les comportements sont factorisables.
  

• Je me suis pas encore penché sur les templates, peut être est-ce le moment?
  

• Le pattern visiteur : l'arme absolue pour ces problèmes de downcasting. Ça permet de pouvoir donner une implémentation différente pour chaque classe fille.

[poukill]

Je me suis pas encore penché sur les templates, peut être est-ce le moment?

Attention, le template method est un pattern, le nom est trompeur... Rien à avoir avec les template C++.

[jblecanard]

Je me suis pas encore penché sur les templates,

Je vote pour le visiteur comme te l'as conseillé Poukill, c'est un pattern utile à connaître.