Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb de communication entre objets

2 réponses
Avatar
Marc
Bonjour à tous,
j'ai un problème d'objets interdépendants tels qu'une modification de l'un
doive entraîner une mise à jour d'autres objets.
Ce problème étant classique, j'ai une idée que je vous soumets avant de la
mettre en oeuvre...
Le principe est inspiré du modèle Observateur mais en instaurant un Centre
de contrôle unique...
Je m'explique :
1) J'introduit une classe de base abstraite CDialog de laquelle doivent
dériver tous les objets susceptibles de "dialoguer" avec d'autres objets (ie
entraînant des mises à jour en cascade...)

class CDialog {
virtual void miseAjour(void)=0;
};

2) Je créé une classe CDialogControl sur le modèle singleton chargée de
contrôler les échanges entre les objets. En gros l'instance unique de cette
classe enregistre toutes les paires de type (appelant,appelé), appelant et
appelé étant identifiés à partir de pointeurs de type CDialog*

- Lorsque je veux créer une liaison, je l'enregistre dans l'instance unique
de cette classe. Avantage : je peux vérifier qu'il n'y a pas de circularité
dans les appels...
- Lorsqu'un objet est modifié, il recherche s'il est enregistré comme
appelant dans l'objet de controle global
- Lorsqu'un objet est détruit, son destructeur peut facilement supprimer
toutes les paires (appelant,appelé) dans lesquelles il apparaît comme
appelant ou appelé

Si j'avais beaucoup d'objets qui "dialoguent" entre eux, ça pourrait faire
une usine à gaz, mais en pratique, je n'aurai pas plus d'une vingtaine
d'objets instanciés simultanéments...

Petit pb pratique :
Si j'ai l'imbrication suivante
class CNiveau1 : public CDialog {

};
class CNiveau2 : public CNiveau1 {

};
lorsque j'instancie un objet de type CNiveau2 comment signifier que je veux
être averti d'une modification intervenue dans les données membres propres à
CNiveau1 ?
Si je veux enregistrer la liaison lorsque je créé un objet CNiveau2 :
appelant=reinterpret_cast<CNiveau1 *>(this)
appelé=this
?
Merci de vos lumières et de vos expériences
Marc

2 réponses

Avatar
Ivan Vecerina
Bonjour,
"Marc" wrote in message
news:3fce2ae7$0$22310$
...
2) Je créé une classe CDialogControl sur le modèle singleton chargée de
contrôler les échanges entre les objets. En gros l'instance unique de
cette

classe enregistre toutes les paires de type (appelant,appelé), appelant et
appelé étant identifiés à partir de pointeurs de type CDialog*

- Lorsque je veux créer une liaison, je l'enregistre dans l'instance
unique

de cette classe. Avantage : je peux vérifier qu'il n'y a pas de
circularité

dans les appels...
- Lorsqu'un objet est modifié, il recherche s'il est enregistré comme
appelant dans l'objet de controle global
- Lorsqu'un objet est détruit, son destructeur peut facilement supprimer
toutes les paires (appelant,appelé) dans lesquelles il apparaît comme
appelant ou appelé
Je ne suis pas fan du controlleur central (sauf peut-être pour la détection

des circularités... qui peut-être pourrait se faire au moment de la
notification). Je serai plutôt pour une communication directe entre
objets (motifs: performance, compatibilité multi-thread).
Aussi, devoir dériver d'une class CDialog (tiens, ça rappellera à bcp
le nom d'une classe MFC) pose problème si un objet souhaite indépendemment
surveiller plusieurs sources (ou dans le cas que tu as décris).

Dans un message précédent (ds le NG anglais, désolé), j'avais esquissé
une approche différente à ce genre de problème, utilisant un objet
membre comme 'adaptor' afin de recevoir les notifications:
http://groups.google.com/groups?threadm=9kvt93%246uh92%241%40ID-86670.news.dfncis.de
et (référencé ds ce premier message):
http://groups.google.com/groups?selm–6698440.46753%40unet.urbanet.ch
La déconnexion est automatique lors de la destruction.

Peut-être y trouveras-tu de l'inspiration...

Amicalement,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form

Avatar
Marc
Merci de tes infos.
Je vais regarder tes liens et examiner tout ça.
Je m'excuse de ne pas avoir répondu + tôt car j'étais parti... en WE
Amicalement
Marc