Discussion :

[HanLee]

Tu as des exemples précis ? Ca m'intéresse.

[Matthieu Brucher]

Ben en fait, dans ton cas, à part redéfinir une fonction virtuelle à chaque fois, celle qui retourne la valeur calculée, je ne vois pas où il faudrait tout redéfinir...

[beckerfriedman]

C'est nécessairement un problème de conception.
L'héritage sert en premier lieu à découper un problème en niveau d'abstraction.

Je reprends ton problème de météo (sans en connaître toute l'étendue, bien sûr).
Imagine que tu aies un premier système basique où soit il fasse soit beau, soit il pleuve.
Un module est chargé de l'affichage de ces évenement météo. Le beau temps est matérialisé par un disque jaune de rayon plus ou moins grand en fonction de la température
attendue, et la pluie par une goutte d'eau plus ou moins haute en fonction du volume de précipitation prévu.
Si je suis ta conception initiale, ce module d'affichage comporte un genre de fonction membre comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
afficher(...)
{
  pour chaque evenement e:
    si (e est un 'beau temps')
        récupérer la température
        afficher un soleil en fonction de cette température
 
   si (e est un 'pluie')
       récupérer le volume de précipitation
       afficher une goutte en fonction de ce volume
}

Ce type de conception est problématique. Elle impose que le module d'affichage détermine le type d'évenement à afficher (c'est le problème que tu rencontres). En d'autre termes, ce module ne peut pas manipuler tous les évenements de manière uniforme.
Elle est de ce fait peu évolutive. Si on souhaite dans un deuxième temps ajouter un autre évenement, de type brouillard par exemple, qui sera représenté par un carré hachuré plus ou moins dense en fonction de la visibilité, il faudra modifier le module qui gère l'affichage.

Une solution simple (mais pas unique) est de déléguer la responsabilité de sa représentation à chaque type d'évenement. Le module d'affichage dresse le tableau général, en dessinant une carte de France, plaçant les villes, etc. Et quand vient le moment de placer un signe représentant l'évenement météo, il 'demande' à cet évenement, soit de lui fournir sa représentation graphique, soit de 'se peindre' à un endroit déterminé.
La fonction d'affichage du module devient

Code :

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

1
2
3
4
5
afficher(...)
{
  pour chaque evenement e
    e.afficher();
}

Dans ce cas, on peut faire jouer les mécanismes dhéritage, et notamment la liaison dynamique. Le module d'affichage ne manipules que des évenements météo, sans savoir s'il s'agit de pluie, soleil ou autre. Chacun de ces évènement particuliers hérite d'une classe mère qui impose de posséder une fonction 'afficher'. Cette fonction est redéfinie dans chaque type d'évènement afin d'y fournir sa représentation graphique spécifique.

Ainsi, le module d'affichage n'a plus besoin de connaître le type réel des évenements qu'il manipule. Du coup, il peut facilement manipuler des listes, vecteurs, tableaux, etc... d'évènements, et l'ajout d'un nouvel évènement (la grêle par exemple) est grandement facilité.

C est exactement ça !!!
Après je dispose d'un nombre connus d'objets météos mais c'est vrai que conceptuellement parlant c'est pas du tout optimisé.
Si j'avais 50 objets faire 50 if c est de la merde, mais vu que j'en avais pas beaucoup ça ne m'a pas sauté aux yeux.
Merci !

[HanLee]

Ben en fait, dans ton cas, à part redéfinir une fonction virtuelle à chaque fois, celle qui retourne la valeur calculée, je ne vois pas où il faudrait tout redéfinir...

Oui ok, c'est bien ce que j'ai dit alors =).
Non mais j'pensais que tu disais qu'il y avait une meilleure méthode que ça, dans le cas de types récursifs.

[Jan Rendek]

Pour modéliser les types récursifs, regarde le design pattern Composite

[Matthieu Brucher]

Oui ok, c'est bien ce que j'ai dit alors =).
Non mais j'pensais que tu disais qu'il y avait une meilleure méthode que ça, dans le cas de types récursifs.

Ben c'est surtout que tu disais qu'il y avait pleins de choses à faire pour que ça marche !
Jan Redek > exactement.

[HanLee]

Ben c'est surtout que tu disais qu'il y avait pleins de choses à faire pour que ça marche !
Jan Redek > exactement.

Désolé, j'voulais que globalement c'était la même quantité de code avec le polymorphisme qu'avec des dynamic_cast.
Sinon j'ai vu pour le composite merci.

[Swoög]

Désolé, j'voulais que globalement c'était la même quantité de code avec le polymorphisme qu'avec des dynamic_cast.
Sinon j'ai vu pour le composite merci.

pour un grand nombre de possibilité : NON carrément pas...

parce que avec le dynamic_cast, non seulement tu dois coder les fonctions membres avec le vrai comportement, mais en plus les if pour faire toutes les possibilités, avec qu'avec le polymorphisme, exit les if...

[Matthieu Brucher]

Sauf qu'il n'y a pas de cast, donc c'est mieux

[Jan Rendek]

On ne mesure pas la qualité d'un bout de code à son nombre de lignes.
Le réel problème de la première solution n'est pas la taille du code, ou l'enchaînement successif de if... then...
Un des objectifs premier de la programmation objet est de favoriser la modularité et la réutilisabilité d'un implantation. L'encapsulation de données et l'utilisation d'abstractions sont des facteurs majeur pour réaliser cet objectif.
Dans l'exemple présent, le premier design crée une dépendence forte entre le module d'affichage et les évènements à afficher. Le module d'affichage a besoin de 'savoir' comment se composent les évènements afin de pouvoir fonctionner. Ceci n'est plus le cas en manipulant une abstraction des évènements et en déléguant aux évènements leur spécificité d'affichage.
En terme de réutilisabilité c'est bien meilleur puisque le module d'affichage peut ultérieurement être utilisé avec n'importe quel type d'objet satisfaisant l'abstraction. En terme de maintenance c'est meilleurs car l'ajout d'un nouveau type d'évènement n'aura aucun impact direct sur le code existant. Si celle-ci provoque une erreur, elle sera forcément localisée dans le nouvel évènement ajouté. De même si les spécifications sur les évènements changent en cours de projet, le module d'affichage ne sera pas touché.

[HanLee]

> Miles : Oui je sais =).

> Jan : Oui pour les lignes de code, et OK pour le reste, ca me convient.

pour un grand nombre de possibilité : NON carrément pas...

parce que avec le dynamic_cast, non seulement tu dois coder les fonctions membres avec le vrai comportement, mais en plus les if pour faire toutes les possibilités, avec qu'avec le polymorphisme, exit les if...

Non justement, dans mon exemple du dynamic_cast le but c'était de ne pas avoir de fonctions membres mais de tout faire de manière "fonctionnelle" (fonctions libres si tu veux, qui manipulent des données).

[Matthieu Brucher]

A la limite, on peut faire une espèce de pattern visiteur dessus
Ce qu'il faut au maximum, c'est permettre l'évolutivité et limiter la modification du code actuel, donc les fonctions libres, ça peut être bien, ou pas dans certains cas.