Application C++ et communication matérielle

Question

Le problème est principalement un problème de conception OOP. J'ai une classe qui gère la connexion et la communication avec le matériel (disons via USB) - CommClass. Il a peu de méthodes - connect(), disconnect(), read(), write(). L'application elle-même a peu d'autres classes qui veulent communiquer avec la même classe CommWhist. La question - comment vous faites habituellement cela? J'ai quelques idées à l'esprit:

1. Dans la classe mère ou en créer une instance principale de CommClass, appelez connect() et pas un pointeur sur toutes les classes (constructeurs). À la fin - disconnect().
2. Chaque méthode de chaque classe crée un objet CommClass dans la pile quand elle en a besoin. - ici le problème est qu'il doit appeler la méthode connect() afin de demander une poignée à l'USB et ainsi de suite à chaque fois ...
3. Utiliser des méthodes statiques de CommClass ...

Answer 1

Si vous prévoyez avoir une seule connexion à l'appareil (disons un périphérique USB) alors il est logique d'avoir une seule instance de votre CommClass ou ICommClass si vous voulez avoir un design plus élégant et travailler avec une interface qui est implémentée par votre CommClass. Vous pouvez également envelopper la connexion (classe ou interface) dans un singleton, de cette façon, vous pouvez vous assurer que la connexion est établie et éliminée une seule fois. Cela fonctionne mieux si vous prévoyez d'utiliser une seule connexion à la fois dans une seule application threadée. Dans un environnement multi-thread ou multi-connexions, vous pouvez essayer d'utiliser un motif de conception object pool.

Answer 2

Je pense que la meilleure solution dépend beaucoup des exigences de votre application et de la nature de votre connexion de communication. Dans le cas le plus simple, ce que vous décrivez en (1) sera probablement suffisant.

Personnellement, je place presque toujours les communications dans un fil séparé. C'est un peu plus compliqué, mais cela peut donner des gains de vitesse significatifs et faire en sorte que votre interface ne soit pas bloquée quand quelque chose d'étrange se produit dans les communications (comme le câble USB). (RS232 comms) utilise une légère variation de ce que vous décrivez en (1). J'ai une classe CComms en tant que membre de mon objet application principal, qui crée un thread pour lancer les communications. J'ai alors un système de message très simple similaire à celui utilisé par Windows qui gère toutes les données de synchronisation de threads entre les threads de communication et l'application principale. L'application principale dispose alors de quelques fonctions simples pour envoyer des messages de communication d'autres classes et renvoyer les réponses à la classe concernée.

J'espère que cela aide un peu ...