Discussion :

[YéTeeh]

Bonjour,

Je suis à la recherche de conseils et d'avis.

Je m'apprête à mettre en place un système de communication entre les instances de mes classes avec des messages.

L'idée est d'avoir un "bureau de poste", auquel s'enregistrent les classes souhaitant recevoir des messages (messageable), les messages envoyés héritant de la classe "message".

Actuellement, lors du transfert des messages j'ai une méthode messageable::process_message( message& m ). C'est alors au destinataire de retrouver le type d'origine du message. Là c'est difficile parce que la classe "message" n'as pas de méthode virtuelle, donc pas de dynamic_cast<>(). Je me suis dit que je pourrais mettre un identifiant à toutes les classes héritant de "message". Le problème c'est que ça devient vite ingérable (genre "quel est le prochain identifiant libre ?"). La solution pourrait être de faire un fichier avec tous les identifiants. Ca me gène parce que ça force un lien entre tous les messages. Peut-être qu'il est possible de générer des identifiants à la compilation ? par métaprogrammation ? je n'en ai aucune idée.

Du coup je pense à une autre méthode. j'enlève la méthode messageable::process_message() et j'ajoute une méthode message::apply_to( messageable& m ). Le type réel du message est alors bien connu, mais c'est au message de retrouver le type réel du messageable. Ceci dit, vu que ce sont les objets qui définissent les messages qui s'appliquent à eux, il ne devrait pas y avoir de doute quant au type du paramètre.

Qu'est-ce que vous pensez de ces deux méthodes ? En voyez vous d'autres ?

merci.

[Mayti4]

La première méthode me semble plus logique.

la classe "message" n'as pas de méthode virtuelle

Et elle ne peut en avoir ?

Disons que tu ais une classe Poste avec une méthode SendMessage et
la classe Message avec une méthode virtuelle GetType.

Au moment où tu dois envoyer un message, tu l'envoies avec SendMessage.

Les classes le reçoivent dans leurs méthode OnMessage, et font l'action nécessaire suivant ce que retourne GetType.

[YéTeeh]

La classe "message" n'a pas de méthode virtuelle parce qu'elle n'en a pas besoin avec le premier modèle. Je pourrais lui en mettre une, mais elle ne servirait qu'au dynamic_cast<>().

Le problème du GetType, c'est qu'il faut un identifiant pour chaque type de message, et ça revient à ce que j'ai noté dans mon post précédent.

[Mayti4]

Le problème du GetType, c'est qu'il faut un identifiant pour chaque type de message, et ça revient à ce que j'ai noté dans mon post précédent.

Si tu ne veux pas d'identifiants, comment veux-tu les différencier ?

Toutes les lettres qui vont au bureau de poste n'ont pas la même adresse..

[YéTeeh]

Si tu ne veux pas d'identifiants, comment veux-tu les différencier ?

Toutes les lettres qui vont au bureau de poste n'ont pas la même adresse..

En fait, le type de la classe est un identifiant en soi, un identifiant du contenu. Pour ce qui est de l'adresse, dans la mesure où je connais le destinataire, il n'y a aucun soucis.

Essayons de clarifier l'état actuel avec un exemple :

Deux personnes sont enregistrées au bureau de poste. Elles peuvent donc recevoir des messages.

Nous avons quatre type de messages : télégramme, courrier, colis et publicité. Tous héritent de "message" pour pouvoir passer par le bureau de poste.

Disons que la première personne veut recevoir des télégrammes et du courrier, la seconde ne veut que des colis et de la publicité.

L'émetteur va faire quelque chose comme :

Code :

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

1
2
telegramme t;
bureau_de_poste.envoyer_message( "personne_1", t );

Mais la personne 1, elle, ne recevra qu'une instance de "message", sans savoir si c'est un télégramme ou un courrier.

Donc là, j'ai deux possibilités :
- soit j'ai ajouté un identifiant à chaque classe de message, et dans deux semaines je me perds en cherchant un identifiant pour un nouveau type de message, qui ne serait pas utilisé par l'un des 50 types de messages déjà existant ;
- soit j'ajoute une méthode virtuelle à la classe message, ce qui me permettra d'utiliser dynamic_cast<>(), même si la méthode n'aura aucun contenu.

[Mayti4]

Donc là, j'ai deux possibilités :
- soit j'ai ajouté un identifiant à chaque classe de message, et dans deux semaines je me perds en cherchant un identifiant pour un nouveau type de message, qui ne serait pas utilisé par l'un des 50 types de messages déjà existant ;

Simple, Identifiant = nom de la classe.

- soit j'ajoute une méthode virtuelle à la classe message, ce qui me permettra d'utiliser dynamic_cast<>(), même si la méthode n'aura aucun contenu.

Tu vas en avoir combien des dynamic_cast, 50 ?

[YéTeeh]

Simple, Identifiant = nom de la classe.

Pas bête, je n'y avait pas pensé.

Tu vas en avoir combien des dynamic_cast, 50 ?

mmh... en gros oui. En pratique, j'en aurait autant que de types de messages que la classe de destination peut traiter. Mais même avec les chaines contenant le nom de la classe, j'aurais une 50-aine de if ... else if ... else if ... ;-)

Je crois que la seconde solution de mon premier post est la plus simple, et la plus classe. En effet, chaque message sais à quel type de classe il s'adresse. C'est implicite lors de la déclaration de la classe du message. Si je suppose que je n'envoie pas de message à quelqu'un qui ne peut le traiter, il n'y aura pas de problème.

Pour reprendre l'exemple ci-dessus, la classe de la personne_1 hériterait de "peut_recevoir_telegramme" et de "peut_recevoir_courrier". Ensuite on défini :

Code :

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

1
2
3
4
5
void telegramme::appliquer_a( messageable m )
{
  peut_recevoir_telegramme* p = (peut_recevoir_telegramme*)(&m);
  p->lire_telegramme( *this );
}

La méthode est virtuelle et le paramètre reste de type "messageable" car le bureau de poste ne stocke que des "messageable".

[Matthieu Brucher]

Ce genre de chose se fait avec un message qui a des classes virtuelles. Sinon, ça ne sert à rien, c'est comme un void*. Le dynamic_cast est évitable, ce système étant un classique.
Déjà, pourquoi ne pas changer le design ? C'est le but du refactoring quand le système commence à atteindre ses limites, et avec des if... ou des dynamic_cast, c'est clairement le cas. En tout cas, ce que tu décris peut être un pattern Command par exemple.

Fais attention, tu ne dois pas avoir de copie quelque part du message sans quoi tu perdrais les différentes dérivations !

[YéTeeh]

Ce genre de chose se fait avec un message qui a des classes virtuelles.

Là je ne comprend pas vraiment. Des classes virtuelles comme dans les trucs d'héritage en losange ? Vous pourriez être plus précis ?

Déjà, pourquoi ne pas changer le design ?

C'est ce que je suis en train de faire ! J'ai implanté la seconde méthode de mon premier post, ça semble fonctionner mais ce n'est peut être pas encore l'idéal.

En tout cas, ce que tu décris peut être un pattern Command par exemple.

Je n'ai jamais entendu parler de ce pattern, je vais me renseigner.

Fais attention, tu ne dois pas avoir de copie quelque part du message sans quoi tu perdrais les différentes dérivations !

Pas de problème ! Toute la transmission se fait par pointeurs et références.

merci