Programmation sous Visual C++ .Net
But final de mon logiciel : piloter plusieurs caméras.
Matériel : SDK (kits de développement) des différentes caméras
 
 
 
Voilà, on m'a soumis l'idée de  
*créer un classe ancêtre CCamera contenant les infos caméras et des héritières CCamera1, CCamera2, etc.
*créer une classe CImage contenant les infos image
*créer une classe CSequence contenant les infos de séquence
 
Problèmes :  
 
-l'héritage est-il vraiment approprié car CCamera seule ne sait rien faire puisque ce sont chaque classe CCameraX avec leurs fonctions propres qui font le travail.
Pour l'instant, CCamera ne me sert qu'à dispatcher les fonctions par exemple pour la connection qui test si la caméra est branchée et récupère les infos caméras, je crée Connect() dans CCamera qui appelle les différentes fonctions Connect() des caméras (seule la classe de la caméra branchée répondra).
Dans CMonProjetApp, j'appelle alors Connect() de CCamera.
 
-Une fois que la caméra est reconnue, comment puis-je faire pour ne travailler qu'avec la classe CCameraX qui lui correspond?
 
 
Voilà, si des programmateurs chevronnés peuvent me donner des conseils de méthode dans mon cas car j'ai beau lire des tas de bouquins sur l'héritage, (classe ancêtre point et classe dérivée pointcouleur par exemple), je ne vois pas comment l'appliquer à mon sujet.
 
 
MERCI D'AVANCE.

tu devrais chercher un cours de c++ et regarder au chapitre polymorphisme ...
 
par exemple...
http://kafka.fr.free.fr/docs/langa [...] de_55.html
 

c'est le but !
 
tu crée tes caméraX, tu les met dans un vecteur de camera *, et apres tu peux faire les appels sans te soucier de savoir a quel type de caméra tu fais appel ...

J'ai exactement la même situation que toi. J'ai une classe ImageData qui est indépendante de la caméra et j'avais une Abstract Base Class (équivalent des interfaces Java) CameraBase et j'étais parti pour la dériver en autant de types de caméras que j'avais à supporter.
Ca me semblait bien et propre. Oui mais...
Tout d'abord chaque camera a ses spécificités, ses options en plus qu'il est intéressant d'utiliser dans certains traitements.
Ensuite j'ai eu des problèmes avec un SDK en particulier qui fait que je ne pouvais me connecter/déconnecter qu'une fois de la camera. Au second essai boum ca plante tout.
Alors j'ai du revoir mon approche. En fait dans mon cas la caméra en elle même m'importe peu. Ce qui compte ce sont les opérations que je fais avec (la manière de les faire).
Par exemple en fonction que la camera est 12 ou 14 ou 16 bits les images récupérées sont à traiter différemment. Certaines caméras sont refroidies et il faut attendre qu'elles soient stabilisées avant de faire des acquisitions. Certaines permettent de s'intéresser à une partie de l'image seulement ce qui permet d'accélérer les temps de transfert. Alors mon interface de base CameraBase ne convenait pas du tout. Les 2/3 des fonctions d'une caméra lui étaient spécifiques. Et à chaque ajout d'une caméra, on découvre une nouvelle spécificité qui nécessite de revoir la classe de base et dons de répercuter les changements sur les classes existantes...
Bref. J'ai viré mon interface CameraBase et créé une classe CameraManager, qui s'adapte elle même en interne à la caméra branchée, et contient tous les traitements utiles.
Pour le SDK qui merde, Disconnect() ne fait rien, les images acquises sont transformées pour gommer les spécificités 12/14/16 bits, etc...
Là ou j'avais CameraBase avec StartCapture, WaitForEndOfCapture, etc... j'ai une fonction DoSequence dans CameraManager qui en fonction du type de camera va faire XXX captures ou demander une séquence de XXX images, etc...

En fait la relation d'héritage est pertinente pour exprimer la relation est un. Alors on se dit "la camera X est une camera", "la camera y est une camera" donc l'héritage c'est ok. Ben dans mon cas non, car la camera X est une camera X, et Y une camera Y, et X et Y s'utilisent différement. Avoir une classe de base commune ça m'obligeait à pourrir mon code de:

ça ou devoir lancer des exceptions OperationNotSupported dans les classes dérivées...
Donc je n'ai plus une classe de base pour les cameras mais une classe de base pour les traitement faits sur les cameras.
Maintenant peut être que dans ton cas les cameras fonctionnent de manière similaire et donc tu peux avoir une classe de base commune.

 
Tu peux pas créer une méthode virtuelle dans CameraBase nommée DoSomething, ce qui donnerait:
 

 
ça oblige à ajouter DoSomething à la classe de base ...
 
Sans tomber dans l'exces d'une interface riche, il me semble que la classe CameraBase  devrait contenir uniquement les fonctions utiles à l'usage d'une caméra. par exemple initialisation, acquisition (par exemple).
Si une caméra propose une acquisition optimisée ou avec refroidissement liquide, c'est à coder dans la classe fille, et non pas : acquisition_optimisée virtuelle (pure) dans la classe de base.
Apres, S'il y a des fonctions de la caméra qui n'ont rien à voir avec  l'usage traditionelle d'une caméra, genre sortie_du _parapluie_par_mauvais_temps();
On peut faire un héritage à 3 niveaux, en créant une classe abstraite CameraWaterProof qui herite de CameraBase. Apres utiliser un dynamic_cast sur CameraWaterProof avant de lui appliquer la méthode sortie_du_parapluie()

 
Je crois que ce que j'ai commencé à faire alors : ta classe CameraManager avait toutes les fonctions possibles et appelait la fonction de la bonne caméra en commençant à chaque fois par un test if sur la caméra branchée?
 

Ben c'est pareil non? Même pour faire un changement de gain par exemple chaque caméra va avoir sa propre fonction de son SDK non?

Avec des fonctionnements parfois très différents des caméras c'est difficile. Le cas du gain par exemple. Certaines caméras n'ont pas cette fonctionnalité, d'autres ont un obscure réglage et d'autres ont un gain automatique...
 

 
Apparement on n'a pas la même utilisation des caméras. J'ai oublié de préciser un truc important : dans mon cas y'a pas de détection dynamique du type de la caméra. Le logiciel est fourni avec et pour une caméra donnée, et il n'y a que celle-là qu'il doive supporter. La définition du type de caméra est faite lors de la compilation.
C'est pour ça que je n'ai pas utilité d'une relation polymorphique entre les caméras, et pourquoi j'ai viré l'héritage. J'ai en fait autant d'implémentation de CameraManager que j'ai de caméras et au moment de la compilation je compile le CameraManager.cpp qu'il faut.
CameraManager.h est par contre le même pour tous.
C'est pour ça que la classe de base CameraBase était un poids pour moi : tout simplement inutile. Si tu dois faire une détection dynamique c'est une autre histoire. Renseigne toi sur le design pattern factory.