Problèmes de conception : centralisation d'informations

Version imprimable

03/05/2012, 22h27
betsprite

Problèmes de conception : centralisation d'informations

Bonsoir tout le monde,

je suis confronté actuellement à un petit problème de conception sur lequel j'aimerais avoir votre avis.

- Dans ma fenêtre principale, je récupère des événements Windows via des callback comme LowLevelMouseProc.

- Par ailleurs, j'ai un singleton ControlerManager dans lequel je possède notamment les objets ControlerCamera (envoi des infos à un serveur) ou encore ControlerEvents (envoi au serveur des infos souris).

- J'utilise alors les objets du singleton Manager pour faire des appels dans les conditions des callbacks windows en effectuant par exemple :

Code:

ControlerManager::getInstance()->getControlerCamera //...

- Dans ces appels, les événements et les infos de la souris récupérés peuvent :

1. Soit être utilisés pour le ControlerCamera et le ControlerEvents en même temps comme wheel event ou encore move event.

2. Soit être utilisés que par l'un des deux controlers. Le ControlerCamera récupère par exemple le clic droit souris contrairement au ControlerEvents.

Le problème que je rencontre est que pour certaines conditions des callbacks Windows, comme pour un déplacement souris, j'ai besoin de récupérer les infos à la fois pour mon ControlerCamera et pour mon ControlerEvents. Je fais donc deux envois des infos (un pour chaque objet) pour ensuite faire le traitement voulu (distincts entre les deux) dans l'objet voulu.

Comment je pourrais faire pour avoir quelque chose de plus optimal ?

Peut être créer un singleton EventManager qui met en commun tous les infos des events et les redistribues après via des accés "get" aux objets voulus ?

Je vous remercie :) N'hésitez pas à me demander plus de précisions si certains points ne vous paraissent pas clairs!
13/05/2012, 09h50
3DArchi

:alerte::alerte:Singletonite aiguë détectée:alerte::alerte:
Cf Etes-vous atteint de Singletonite ?

Prescription recommandée : Boost.Signal (lectures intéressantes : les notifications de POCO: code et doc)
15/05/2012, 10h38
Emmanuel Deloget

Citation:

Envoyé par 3DArchi

:alerte::alerte:Singletonite aiguë détectée:alerte::alerte:
Cf Etes-vous atteint de Singletonite ?

Prescription recommandée : Boost.Signal (lectures intéressantes : les notifications de POCO: code et doc)

Pour plus d'info sur la Singletonite, il faut se rappeler que la maladie est trop souvent mortelle pour les projets. Si on la combine à la Managerite, j'ai peur que les conséquences n'en soient que plus funestes encore, car les deux maladies se stimulent l'une et l'autre afin d'espérer arriver au plus tôt à pourrir le code.

Sinon,

Citation:

Le problème que je rencontre est que pour certaines conditions des callbacks Windows, comme pour un déplacement souris, j'ai besoin de récupérer les infos à la fois pour mon ControlerCamera et pour mon ControlerEvents. Je fais donc deux envois des infos (un pour chaque objet) pour ensuite faire le traitement voulu (distincts entre les deux) dans l'objet voulu.

Comment je pourrais faire pour avoir quelque chose de plus optimal ?

Soyons pragmatique. Deux entités souhaitent avoir accès à la même information. Je n'ai pas 36 solutions différentes :

* soit j'envoie deux fois l'information, ce que tu souhaite visiblement éviter (PUSH)
* soit je vais récupérer deux fois la même information (PULL)

Dans les deux cas, et en admettant que les traitements soient asynchrones et non bloquant, je vais faire au pire deux copie de l'information souhaité (ça peut être réduit à 0 copie, en utilisant par exemple des pointeurs). Il n'y a pas de gain particulier qu'on utilise l'une ou l'autre de ces techniques (PUSH ou PULL).

Par contre, dans le cas du PUSH, on peut se permettre de ne réveiller que les destinataires réels du message (qui se sont probablement enregistré avant). Dans le cas du PULL, ce n'est pas possible: tous les destinataires possibles doivent vérifier s'ils sont bien les destinataires réels ou non, donc ils doivent tous être actifs. Le PULL est donc bien souvent moins efficace que le PUSH - c'est pour ça qu'on le réserve généralement à des architecture bien spécifique (client / serveur, ...). Le PULL offre aussi un autre problème : quelle est la durée de vie du message ?

Au niveau architecture, ce que j'entrevois reste relativement simple :

* Pour le PULL, un message_repository contenant plusieurs message_queue (par exemple, une par type d'information : message en provenance de la souris, du clavier,...) est rempli par un message_picker. Les clients surveillent les message_queue qui les intéressent et récupère les messages qu'ils veulent traiter. Ca suppose l'implémentation d'un système permettant N lectures du même message avant que celui-ci ne soit détruit automatiquement. Ce n'est pas un problème trivial.

* Pour le PUSH, un message_picker récupère les messages systèmes et les envoie à un message_dispatcher. Celui-ci possède une liste de clients (cf. signal/slot ou le pattern observeur) et chaque client reçoit le message avant qu'il ne soit détruit.

En tout état de cause, personne n'a besoin d'être un singleton, et personne n'a besoin d'être un manager. On pourrait argumenter du fait que toutes les classes sont des managers (après tout, elles assurent la gestion de quelque chose) mais on ne va pas le faire. Certaines des classes citées ci-dessus peuvent avoir un grand nombre d'utilisateur (encore que), mais ça ne justifie jamais l'utilisation d'un singleton.