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.

[b Oo]

Imaginons alors que j'ai une classe etreVivant.
Je veux faire une classe Animal et une autre Vegetal.

Un animal est un etre vivant de meme que vegetal donc ici je fais un héritage ?
Les etres vivants sont composés d'animaux et de vegetaux, je fais une composition ?

[JolyLoic]

Là, tu as un article différent :

Un animal est UN etre vivant de meme que vegetal donc ici je fais un héritage ?
LES etres vivants sont composés d'animaux et de vegetaux, je fais une composition ?

Si tu as une classe qui représente UN être vivant, et une classe qui représente UN animal, je ne vois pas trop quelle composition tu veux faire.

Peut-être que les éléments trouvable sur http://archive.eiffel.com/doc/manual...c/acrobat.html pourront te donner des idées plus claires (en particulier Using inheritance well) ?

[b Oo]

Euh oui d'accord,
en plus ce qu j'ai ecrit est le pattern composite.
La classe etre vivant qui a les 2 sous classes Animal et Vegetal
et une classe EtresVivants qui contient des etreVivant.

[JolyLoic]

Pas vraiment. Le design pattern composite, dans ton cas, ce serait si tu avais un troisième type d'être "vivant", nommé Colonie, par exemple, qui soit considéré comme un être vivant à part entière, qui naisse, vive, meurt, se reproduise... Et qui lui même soit composé d'être vivants (des fourmis, des pucerons, des champignons... voire d'autre Colonies), définissant ainsi une hiérarchie d'instances.

Ce qui marque le composite, c'est cette classe qui dérive de la classe de base et possède une collection d'éléments de la classe de base.

[Luc Hermitte]

Une petite mise en garde. Les "est-un" de la vraie vie, ce sont pas forcément des "est-un" valides dans le paradigme objet. L'exemple typique est le carré qui n'est pas un rectangle contrairement à ce que notre intuition nous dicte.

Pour tes hiérarchies de vivant, en quoi être vivant est important? Quel est le comportement que ces choses ont que les autres choses n'ont pas ?
Tes exemples sont beaucoup trop génériques et sujets à pinaillages pour que je puisse te donner une réponse définitive sur le comment je ferai.
Le vivant, je risque plutôt de le casser en Comestible, Viellit et diverses autres choses (Interface/traits/...). Et pour la colonie de fourmies qui parrait vivante, tous ne seront pas forcément applicables.

En fait, je n'aime pas trop m'appuyer sur ces modélisations de la réalité, car j'ai l'impression que l'on touche aux limites de la modélisation OO à base d'héritage. Une modélisation ne sera valide que dans le cadre de la finesse et du réalisme dont on a vraiment besoin.