Discussion :

[erqsor]

Bonjour,

Bon le titre est assez explicite je pense.
j'ai besoin (pour un projet professionnel) de savoir comment 'bien organiser' les échanges de messages/commandes formalisées entre plusieurs objets dans un programme (Par exemple entre un objet principal et différents modules associés).

J'aimerais pouvoir envoyer des commandes à mes modules de manière formalisée tout en passant des arguments de différents types, comment procéder proprement ?
J'aimerais garder une grande évolutivité pour la suite du projet.
Dois-je passer par du void*, des conteneurs de la STL, ou encore des structures personnalisées ? Ou alors existe t'il une autre méthode ?

Le mieux serait encore de me rediriger vers des documentations ou dossiers qui traitent la question en détail.

merci d'avance.

[mister3957]

Quel est l'intérêt de passer des "ordres" de manière "générique" si l'appelant comme le receveur doivent les configurer/manipuler sous leur forme concrête ?

Regarde tout de même du côté du pattern de fabrique abstraite.

[white_tentacle]

Ça ressemble à un système de signaux ce que tu décris.

Auquel cas, 3 pistes :
- Qt
- boost::signals
- les signaux de gtk

[mister3957]

Les signaux c'est pas plutôt pour réceptionner des évennements et non envoyer des actions ?

[white_tentacle]

Les signaux c'est pas plutôt pour réceptionner des évennements et non envoyer des actions ?

S'il y a un récepteur, c'est qu'il y a un émetteur, non ?

[mister3957]

Mais dans ce cas ça voudrai dire que le module, récepteur, va devoir s'abonner à la partie principale, l'emetteur ?

Donc le module a besoin de connaître celui qui l'utilise pour s'abonner à son signal et recevoir les actions... Ca fonctionne à l'envers ça non ?

A mon avis les signaux boost et Qt sont utilisés différemments et je ne connais que ceux de Qt, c'est pour ça que j'ai du mal à comprendre.

[white_tentacle]

Pourquoi voudrais-tu que ça fonctionne comme ça ?

Le récepteur fournit une interface pour être notifié (sous Qt, un slot), et c'est bien l'émetteur qui émet le signal. C'est l'émetteur qui a connaissance du récepteur.

[mister3957]

Ouais je vois ce que tu veux dire. Tu veux faire comme dans les MFC où le programme principal gueule en l'air "JaiBesoinDeCa(CaExactement)" et que chaque module reçoit l'évennement, analysent rapidement le "CaExactement" à la recherche de "est-ce que c'est à moi qu'il demande ?"

D'une part c'est très limite, d'autre part avec les signaux, chaque module aura besoin de connaître l'appelant pour s'y abonner (le slot - récepteur doit s'abonner au signal - emetteur), et donc ils sont dépendants et ne peuvent plus être déplacés, où alors faut mettre en place une sorte de FrameWork, dont l'utilisation sur les autres projets serait la seule contrainte afin de poursuivre l'évolutivité...

Il doit sûrement y avoir quelque chose de plus correct à faire.

[white_tentacle]

Non, je n'ai jamais dit ça, je ne sais pas pourquoi tu veux que j'ai dit ça . J'ai dit :

C'est l'émetteur qui a connaissance du récepteur.

En gros, le récepteur fournit une interface pour être notifié, et l'emetteur le notifie au moyen d'un signal. En Qt, c'est même plus subtil que ça, car potentiellement, ni l'émetteur ni le récepteur ne se connaissent, ils sont simplement reliés par un tiers (au moyen de connect), à condition que leurs interfaces (resp signal et slot) soient compatibles.

[mister3957]

Ué mais dans ce cas, le module fournit une interface non pour être notifié qu'il s'est passé quelque chose au niveau de la partie principale, mais que ce dernier lui a demandé quelque chose.

Y'a un moyen plus simple pour être notifier lorsque l'on nous demande de faire un traitement, c'est de faire une fonction normale ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class CMonModule
{
public:
   CMonModule()
   {
       // Comment aller s'inscrire auprès du signal de l'emetteur sans le connaître ?
   }
 
   void FaitCa(); // direct
   void OnEmetteurDemandeDeFaireCa(); // par signaux, débile ?
};

[Cheps]

Comme précisé par tentacle, en Qt tu "connect" deux objets qui peuvent ne pas se connaître du tout. Si tu as deux objets a et b de classes A et B, aucune des deux classes ne doit inclure l'autre pour que a et b puisse communiquer par signaux. Alors que dans ton cas tu devrais bel et bien le faire. Les signaux, ca s'utilise beaucoup dans les GUI avec Qt où les widgets communiquent entre-eux sans forcément se connaître. Il suffit qu'un tiers les relie entre eux.

Evidemment, pour que 2 objets puissent communiquer en C++, il faut à un moment donné qu'il y aie un lien qui soit créé. Ca peut se faire de beaucoup de manières différentes, mais il faut soit qu'un des deux objets connaisse l'autre, soit qu'un objet tiers les connaisse les deux.

[koala01]

Salut,

Les fonctions membres faisant partie de l'interface publique d'une classe (ou d'une structure) devraient être considérées de manière générale comme la possibilité offerte par la classe en question de... recevoir un message.

Ce message peut, bien sur, prendre la forme de

fais ceci, s'il te plait

mais rien n'empêche qu'il prenne la forme de

au cas où ça a un intérêt pour toi, j'ai fait cela

A partir de là, il faut analyser la situation pour savoir

• si le flux de message va dans un sens, dans l'autre ou dans les deux (qu'il y a un dialogue entre les objets)
• s'il y a un rapport de "contenant à contenu" entre les différents objets
• si ce sera toujours le même objet d'un type qui enverra son message au même objet de l'autre type, ou s'il y a pluralité des émetteurs et / ou des récepteurs
• dans quelle circonstance le message doit être envoyé: suite à une action sur "l'émetteur" lui-même ou suite à une action "hors de l'émetteur"
• les contraintes de (d'inter) dépendance que tu veux / dois respecter
• si tu utilises ou veux utiliser les possibilités proposées par les bibliothèques tierces que tu utilise par ailleurs
• ...toutes les situations particulières auxquelles je n'ai pas pensé "en première approche"...

Tous ces points de vue correctement estimés t'orienteront vers la solution qui est la plus adaptée à ton cas, sachant que, dans certains cas, tu préférera un couplage "fort" proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class B;
class A
{
    public:
        A(B* b):b(b){assert(b!=0);}
        void updateAfterChanging();
    private:
        B* b;
}
class B
{
    public:
        B():a( this ){}
        void doSomething()
        {
            /*...*/
            updateAfterChanging();
        }
        void myAIsUpdated(){/*...*/}
    private:
        A a;
}
void A::updateAfterChanging()
{
    /*...*/
    b->myAIsUpdated();
}

et que dans d'autres cas, tu sera dans une situation dans laquelle A n'a strictement aucune connaissance de B

Le mieux de l'histoire, c'est que, dans un même projet, il n'est pas du tout exclu que tu fasse des choix différents selon l'analyse des différents types que tu manipule dans ton projet (couplage fort entre A et B mais C n'ayant aucune connaissance de D, alors qu'il y a communication entre les deux )

[erqsor]

Loin de moi l'envie d'avoir lancé une polémique sur les signaux. En tous cas merci pour vos réponses, je vais aller me documenter sur tout ça.