Discussion :

[b Oo]

Bonjour,
j'ai une hiérarchie de classes de ce style

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
                                    A
                                /       \
                              B           E  
                          /      \      /   \
                        C          D   E1  E2         
                      /   \      /   \ 
                    C1     C2   D1  D2                                             
 
A, B, E, C, D sont abstraites.
C1,C2 sont les classes qui héritent de C et qui sont concretes
de même pour D1, ...

J'ai un conteneur monConteneur de A *. B possède une méthode toto et E non.
Je voudrais pour chaque élément de monConteur appelé la méthode toto si c'est un B.
Existe t-il une méthode propre de faire ceci ?
Pour l'instant je ne vois que :

Code :

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

1
2
3
4
 
pour tout les elément de monConteneur faire
   si classMereDeElementCourant = b alors
      appeler toto

[Luc Hermitte]

Quand on veut réaliser ce genre de choses, souvent, c'est que l'on a foiré son design.
Sinon, un visiteur peut-être ?

[b Oo]

Arf c'est bien ce que je craignais , ma conception n'est pas bonne.

En fait B et E ne devrait pas etre des classes filles de A mais A devrait contenir des B et des E.

Luc j'aimerais savoir s'il y a quelques règles pour choisir entre héritage et composition (lorsque les 2 solutions semblent envisageables).

Je sais qu'il est recommandé de faire de la composition plutôt que de l'heritage lorsqu'on a le choix mais je ne sais pas vraiment pourquoi.

[loufoque]

Bah c'est relativement simple.
Si B est un sous-type de A alors tu dérives. Sinon, non.

[b Oo]

Par exemple si tu as une classe Personne.
Si je fais une classe PersonneAgee et JeunePersonne.
Tu fais un héritage ou une composition ?
On peut le voir des 2 manieres non ?
(tu vas me dire que tu fais de l'héritage)

[Luc Hermitte]

Aucun des deux. Je stocke l'âge et en aucun cas je ne spécialise cette classe de la sorte.
Je ne te raconte pas la compléxité du changement de type d'une "grosse" entité au fil de son évolution. jeune -> "..." -> agé
Je préfère avoir un trait del'entité qui au besoin changera de catégorie/type.

Je pense que tu devrais utiliser un exemple moins générique.

Le choix sinon ? Hum...
* modélisation de la relation "est-un", mise en oeuvre d'une subtituabilité, .. => héritage public
* réutilisation de code
- couplage statique et fort acceptable => héritage privé
- sinon, 90% du temps => composition

Pour les cas intermédiaires, cela dépend. Toujours est-il que j'évite au maximum l'héritage public quand le LSP (recherche avancée!) n'est pas recherché, et qu'il ne peut pas être correctement mis en oeuvre.