Faire communiquer des objets : oui mais comment ?

Bonjour à toutes et à tous !

Je cherche à faire communiquer des objets. Jusque là, j'avais opté pour une stratégie de composition : A contient un pointeur sur B et demande à B le service nécessaire.
Le souci c'est que ça devient vite compliqué et pas flexible.

J'essaie de penser autrement :
A n'a en fait besoin que du résultat/produit/donnée rendu par le service de B. Il n'a pas besoin de connaître ni B ni son service.
On peut imaginer un objet intermédiaire C qui joue le rôle de tampon. Il demande le service à B et transmet la réponse à A.

Le truc c'est qu'il y a en fait quelques objets qui communiquent les uns avec les autres (X et Y envoie chacun un message à Z qui les intègre et envoie une réponse à W), et il y a différentes communications possible qui doivent s'opérer dans une certaines séquence. Faut-il un objet responsable de chaque type de communication ?
Quelle est la solution pour implémenter ça ? Après un peu de biblio, j'ai vu (pas forcément compris intégralement) des trucs sur :
- la chaîne de responsabilité
- le médiateur
- l'observateur
- les évènements (par exemple )

Quelle solution me conseillez-vous ? Il manque peut être des infos pour décider, dites moi juste lesquelles ;)
Est-ce compliqué d'initialiser ces graphes de communication ?

Merci d'avance !

[Edit] Les connexions entre objets ne peuvent pas être connues à l'avance, elles sont déterminées à l'execution en lisant un fichier de configuration

Salut,

En fait, ce que tu appelle "système d'événements" est généralement plutôt appelé "système de signaux et de slots", car le terme événement prend régulièrement une signification particulière qui est beaucoup plus précise encore.

Cependant, je crois effectivement que, à moins qu'il n'y ait vraiment de bonnes raisons pour partir sur un système de composition, la solution la plus évolutive passe, effectivement, par l'utilisation d'un système de signaux et de slot :

Je ne vois pas vraiment en quoi la chaine de responsabilité pourrait avoir un quelconque intérêt pour apporter une solution à ton problème. Généralement, ce patron de conception est utilisé dans le but de déterminer un nombre clairement établi de possibilités qui seront testées à l'exécution.

Le patron de conception observateur est le patron qui a servi de base à la mise au point des systèmes de signaux et de slots : lorsqu'un objet (l'observé, dans le patron de conception) a une information a transmettre, il émet un signal auquel les objets intéressés par cette information viendront se connecter (les observateurs dans le patron de conception). A charge pour l'observateur d'aller se connecter au signal qui l'intéresse.

Avant l'arrivée de C++11, j'aurais volontiers conseillé en priorité d'utiliser boost::signals2 qui fournit un système de signaux et de slots complet. Mais, depuis que C++11 est arrivé, il est tout à fait possible de mettre un tel système en place en moins de deux cents lignes de code (je le sais, je viens de le faire :P)

Quant à savoir si, dans ta situation, il est plus facile de passer par boost::signals2 ou d'en fournir une implémentation personnelle, je dirais volontiers que cela dépendra fortement de ton niveau ;) : en tant que débutant, tu arriveras bien plus facilement à un résultat cohérent en utilisant boost::signals2. En tant que développeur avancé, tu pourrait apprécier de ne pas imposer une dépendance supplémentaire, et trouver un certain intérêt à fournir ton implémentation perso ;)

Citation:

---

en tant que débutant, tu arriveras bien plus facilement à un résultat cohérent en utilisant boost::signals2. En tant que développeur avancé, tu pourrait apprécier de ne pas imposer une dépendance supplémentaire, et trouver un certain intérêt à fournir ton implémentation perso

---

On va plutôt prendre l'option numéro 1 alors ! :D
C'est parti pour quelques tutos boost::signal2 ! :D

[Edit] oups ! Tout à mon euphorie j'en avais oublié l'essentiel : :merci:

Re-salut !

J'avance dans mes reflexions sinon que dans le code... ;)

Il y a plusieurs objets utilisables pour une exécutation du programme (à piocher dans des bibliothèques).
Le choix des objets et l'assignation des slots/signaux entre les objets choisis dépend des choix utilisateurs.
Certaines caractéristiques des objets choisis restreignent l'utilisateurs dans la configuration (donc d'une certaine manière l'interface devient dépendante des objets-métiers définis par l'utilisateur).

J'ai donc l'impression qu'il y a un va et vient permanent entre l'interface graphique et les objets métiers.
La question que je me pose, c'est si je dois utiliser deux systèmes de signaux et slots (boost:signal2 pour les objets métiers, et Qt pour l'interface) ?

Citation:

---

Envoyé par Seabirds

Il y a plusieurs objets utilisables pour une exécutation du programme (à piocher dans des bibliothèques).

---

Exécutation :question:8O8O:? C'est quoi c'ette bête :question: Voulais tu parler de "exécution", peut être :question: :D

Le choix des objets et l'assignation des slots/signaux entre les objets choisis dépend des choix utilisateurs.
Certaines caractéristiques des objets choisis restreignent l'utilisateurs dans la configuration (donc d'une certaine manière l'interface devient dépendante des objets-métiers définis par l'utilisateur).

Citation:

---

J'ai donc l'impression qu'il y a un va et vient permanent entre l'interface graphique et les objets métiers.

---

Humm... cela arrive très régulièrement, je t'en fais pas... Mais il est vraiment très important de faire en sorte de faire une différence très nette entre ce qui vient de l'IHM et ce qui vient de tes données métiers.

Autrement, tu risques de foncer très rapidement dans un mur que tu n'auras pas vu monter ;)

Citation:

---

La question que je me pose, c'est si je dois utiliser deux systèmes de signaux et slots (boost:signal2 pour les objets métiers, et Qt pour l'interface) ?

---

Humm... j'aurais tendance (mais je suis perfectionniste à ce niveau) à dire que tout ce qui permet à tes données métier de communiquer entre elles devrait être géré à coup de boost::signals2, histoire d'éviter d'aller "polluer" tes données métier avec des spécificités propres à Qt. et de n'utiliser le système de signaux et de slot que pour permettre la communication entre la vue et le contrôleur (enfin, entre la vue et le délégué dans le cas de Qt).

De manière générale, j'irais même jusqu'à dire que tes données métier ne devraient jamais dépendre d'autre chose que de la bibliothèque standard, de boost et de certaines bibliothèques externes le cas échant, mais certainement pas Qt

Mais, comme je viens de le dire, je suis peut être un peu trop perfectionniste à ce sujet, et bien que je persiste et signe en disant que cela représente la solution qui te permettra le plus d'évolutions imprévues, j'ai aussi bien conscience du fait qu'il est parfois assez difficile -- surtout pour un débutant -- d'arriver à éviter d'aller polluer les données métiers avec des fonctionnalités propres à Qt!

Je vais donc exprimer un conseil qu'il te sera beaucoup plus facile de suivre sous la forme de

Citation:

---

Essayes, autant que possible, d'éviter d'imposer les fonctionnalités issues de Qt (QString, QVector, QMap, ... système de signaux et de slot de Qt) au niveau de tes données métier, mais, si tu vois que cela rend la tâche beaucoup plus compliquée pour ton niveau, ne te casses pas trop la tête, et utilises ces fonctionnalités, y compris dans tes données métier ;)

---

Ceci étant dit, je ne te cache pas que je suis pour le moins intrigué par ta demande de manière générale. Car, soit tu travailles sur un projet perso, et je te conseillerais volontiers de le remettre dans tes tiroirs pour "quelques mois" (le temps de t'habituer un peu avec des projets plus simples), soit tu travailles en tant que "junior developper" dans une équipe professionnelle, et, dans ce cas là, ton chef de projet ou ton lead technique devrait pouvoir orienter tes réflexions...

J'ai l'intuition indéfinissable que tu es dans le premier cas que je viens de citer, même si je peux toujours me tromper (ma boule de crystal est quelque peu floue, ces derniers temps :P). Mais si je ne me trompe effectivement pas, tu devrais peut-être essayer de trouver un projet "un tout petit peu moins complexe" pour te "faire les dents" et "gagner tes gallons", avant de revenir sur celui-ci ;)

Comment ça, le verbe executationner n'existe donc pas ? :weird: (sorry)

Citation:

---

Essayes, autant que possible, d'éviter d'imposer les fonctionnalités issues de Qt (QString, QVector, QMap, ... système de signaux et de slot de Qt) au niveau de tes données métier, mais, si tu vois que cela rend la tâche beaucoup plus compliquée pour ton niveau, ne te casses pas trop la tête, et utilises ces fonctionnalités, y compris dans tes données métier

---

Super, merci pour le conseil. Je me doutais bien que ça allait être une réponse du genre, mais du coup je suis rassuré sur l'option ;)

Citation:

---

Ceci étant dit, je ne te cache pas que je suis pour le moins intrigué par ta demande de manière générale. Car, soit tu travailles sur un projet perso, et je te conseillerais volontiers de le remettre dans tes tiroirs pour "quelques mois" (le temps de t'habituer un peu avec des projets plus simples), soit tu travailles en tant que "junior developper" dans une équipe professionnelle, et, dans ce cas là, ton chef de projet ou ton lead technique devrait pouvoir orienter tes réflexions...

---

C'est en fait un projet de thèse interdisciplinaire, et c'est moi le thésard (donc je suis aussi étudiant, c'est bizarre ce statut ;) ).
Bien que le projet soit à cheval sur plusieurs discipline, il s'est vite avéré avoir une dominante informatique, mais ce n'est pas mon background, et pour l'instant il n'y a pas de tuteur "C++" dans ce projet (mais c'est en cours de réflexion). C'est pas évident à gérer, mais j'aime bien :)

Ta remarque finale vient cependant à point, j'ai passé les deux derniers jours à essayer de découper cet inextricable modèle statistique en sous projets gérables et complémentaires. Pas évident non plus. Je pense néanmoins qu'il va être difficile d'avoir des résultats exploitables avec ces sous projets ;)

Merci pour ta réponse !

Je dois rencontrer Seabirds aujourd'hui pour discuter de son projet, on ne manquera pas d'en reparler, c'est certain :D

Je sais que seabirds a choisi boost::signal2 plutôt que de faire sa propre implémentation, mais je suis tombé hier sur un article de blog intéressant sur le sujet: https://isocpp.org/blog/2016/02/auto...in-cpp-nercury

C'est une proposition d'implémentation du pattern observateur qui utilise le couple std::shared_ptr / std::weak_ptr. Le call-back qui sert à gérer la notification est conservé par le client dans un shared_ptr et par la class de dispatch dans un weak_ptr: de sorte que la liste des souscripteurs peut-être nettoyée automatiquement au lieu qu'il soit nécessaire à un client de se désinscrire. Cela me paraît intelligent, je ne sais pas ce que vous en pensez.

Citation:

---

Envoyé par stendhal666

Je sais que seabirds a choisi boost::signal2 plutôt que de faire sa propre implémentation, mais je suis tombé hier sur un article de blog intéressant sur le sujet: https://isocpp.org/blog/2016/02/auto...in-cpp-nercury

C'est une proposition d'implémentation du pattern observateur qui utilise le couple std::shared_ptr / std::weak_ptr. Le call-back qui sert à gérer la notification est conservé par le client dans un shared_ptr et par la class de dispatch dans un weak_ptr: de sorte que la liste des souscripteurs peut-être nettoyée automatiquement au lieu qu'il soit nécessaire à un client de se désinscrire. Cela me paraît intelligent, je ne sais pas ce que vous en pensez.

---

Ben, à vrai dire, je viens justement de terminer la rédaction d'un article (en relecture technique, un peu de patience et il sera dispo pour tout le monde ;) ) dans lequel j'implémente un système de signaux et de slots en moins de deux cents lignes de code (à peu près 300 si on compte les cartouches "doxygen" et les commentaires relatifs à la licence :P ) ... Si ca intérese quelqu'un, je peux diffuser le code et les exemples d'utilisation avant l'article ;)

Citation:

---

Envoyé par Seabirds

Super, merci pour le conseil. Je me doutais bien que ça allait être une réponse du genre, mais du coup je suis rassuré sur l'option ;)

---

Attention quand même, l'idée reste toujours de n'utiliser cette option qu'en tout dernier recours! Je ne peux pas t'empêcher d'y avoir recours, mais je ne le cautionnerai jamais (en tout cas publiquement ) :D

Citation:

---

Ben, à vrai dire, je viens justement de terminer la rédaction d'un article (en relecture technique, un peu de patience et il sera dispo pour tout le monde ) dans lequel j'implémente un système de signaux et de slots en moins de deux cents lignes de code (à peu près 300 si on compte les cartouches "doxygen" et les commentaires relatifs à la licence ) ... Si ca intérese quelqu'un, je peux diffuser le code et les exemples d'utilisation avant l'article

---

Je viens d'y jeter un oeil rapide, il a l'air très bien, dans la lignée du précédent!

Donc toi tu demandes directement le weak_ptr. Dans l'article l'idée est de prendre le callable par référence universelle, de créer le shared_ptr, en conserver une trace sous forme de weak_ptr et de le retourner à celui qui a réclamé la connection. Je ne sais pas quel est ton avis sur ce parti pris?

Juste en passant (je n'ai pas eu le temps de lire précisément ton article), je me demande s'il n'y a pas un risque là:

Code:

---

1 2 3

void disconnect(size_t id) const{ const_cast<SigType &>(*this).slots_.erase(id); }

---

En effet, lors du parcours des slots qu'on voit là:

Code:

---

1 2 3 4 5 6

void operator() (Args ... args) const{ for(auto const & it : slots_){ if(!it.second.conn->blocked()) it.second.slot(args ...); } }

---

si it.second.slot(args...) fait un appel à disconnect(), il peut y avoir invalidation des itérateurs, non? C'est toujours le même problème avec erase... En fait, pour std::map, qui est implémenté comme un arbre auto-équilibré si je ne me trompe pas, le même problème peut arriver s'il y a un appel a connect() dans un des signaux, puisqu'il peut y avoir un rebalancement de l'arbre. Bref, peut-être faut-il un système de lock sur les slots pendant le parcours.

Citation:

---

Envoyé par stendhal666

Je viens d'y jeter un oeil rapide, il a l'air très bien, dans la lignée du précédent!

Donc toi tu demandes directement le weak_ptr. Dans l'article l'idée est de prendre le callable par référence universelle, de créer le shared_ptr, en conserver une trace sous forme de weak_ptr et de le retourner à celui qui a réclamé la connection. Je ne sais pas quel est ton avis sur ce parti pris?

---

En fait, mon système de signaux est -- très certainement perfectible, par exemple, parce que les slots ne sont pas prévus pour renvoyer une valeur ;) Mais, l'un dans l'autre, c'est généralement ce qui se passe avec les signaux (en tout cas, peu de slot renvoient une valeur dans Qt... je ne sais d'ailleurs même pas s'il y en a un seul qui le fasse :P)

Citation:

---

Juste en passant (je n'ai pas eu le temps de lire précisément ton article), je me demande s'il n'y a pas un risque là:

Code:

---

1 2 3

void disconnect(size_t id) const{ const_cast<SigType &>(*this).slots_.erase(id); }

---

---

Tu as mal lu le code, parce qu'il n'y a pas de const_cast :D :D ... j'y reviens tout de suite (*)

En effet, lors du parcours des slots qu'on voit là:

Code:

---

1 2 3 4 5 6

void operator() (Args ... args) const{ for(auto const & it : slots_){ if(!it.second.conn->blocked()) it.second.slot(args ...); } }

---

si it.second.slot(args...) fait un appel à disconnect(), il peut y avoir invalidation des itérateurs, non? C'est toujours le même problème avec erase... En fait, pour std::map, qui est implémenté comme un arbre auto-équilibré si je ne me trompe pas, le même problème peut arriver s'il y a un appel a connect() dans un des signaux, puisqu'il peut y avoir un rebalancement de l'arbre. Bref, peut-être faut-il un système de lock sur les slots pendant le parcours.[/QUOTE]En fait, il n'y a que l'itérateur sur les éléments supprimés qui sont invalidés. Et si le slot appelé décide de se déconnecter, alors, oui, il pourrait effectivement y avoir un problème ;). Mais, dans aucun cas le slot n'est sensé connaitre le signal. Dans le pire des cas, il ne connait que la connexion ;)

Tu me diras qu'il pourrait profiter de la connexion pour demander la déconnexion, mais il s'agit d'être sur de son coup avant de déconnecter un slot, car il est généralement très difficile d'essayer de s'y reconnecter "après coup". C'est pour cela que la connexion fournit le moyen de bloquer le signal, afin d'éviter que le slot associé ne doive réagir à un signal qui ne l'intéresse temporairement pas ;)

(*)Je ne fais pas de const_cast, mais je considère que en dehors de l'identifiant de la connexion, la quasi totalité des données manipulées par le pimpl de la connexion et par le signal sont en fait des données "en cache" car elle ne modifient pas le seul état qui nous intéresse vraiment en tant qu'utilisateur à savoir: que l'instance (de signal ou de connexion) existe ou non :P

Car, dans le pire des cas, c'est l'existence (ou plutôt la destruction) de la donnée au départ de laquelle on va appeler une fonction membre statique qui risque de poser problème : les fonctions libres et les fonctions membres statiques ne dépendent d'aucune donnée qui doit exister et, de l'autre coté, si le signal est détruit avant la donnée dont est issue la fonction membre non statique connectée au signal, il n'y a aucun problème non plus : la fonction ne sera de toutes façons plus appelée ;)

Du coup, de nombreuses données sont déclarées mutables, ce qui me permet de proposer les fonctions membres publiques sous une forme constante, ce qui m'évite justement d'avoir à contourner le fait que je ne peux accéder à certaines données que sous la forme de références constantes :P