Discussion :

[Chachane]

Bonjour,
J'ai un p�riph�rique de gestion de pression et d'analyse du milieu aqueux auquel je dois acc�der par ioctl apr�s ouverture d'un fd.
J'ai de plus un nombre non n�gligeable de fonctions outils �l�mentaires.

Pour mon design, je pensais faire une classe d�acc�s au p�riph�rique qui utilise une classe contenant les tools.
Qu'est ce que vous en pensez ?

Merci

[Waether]

Yop !

Le design patern c'est loin d'�tre ma sp�cialit� mais on sait jamais ^^

Personnellement si tu veux pouvoir g�rer plusieurs types de p�riph�riques je te conseil une interface IPeripherique avec une class pour chacun. Apr�s tu mets les m�thodes d'acc�s aux infos � l'int�rieur.

Mais si tu as qu'un seul p�riph�rique et que tu ne comptes pas en ajouter autant faire une class simple sans trop s'emb�ter. Apr�s suivant si c'est pour toi ou pro y a plus ou moins de propret� � avoir, � toi de voir pour �a.

Pr�voir un ajout de p�riph�rique est toujours bon � prendre �a fait moins de boulot au moment ou faudra le faire, puis �a rajoute pas vraiment beaucoup de taf.

Voil� en esp�rant t'avoir aider =)

[koala01]

Salut,

Yop !

Personnellement si tu veux pouvoir g�rer plusieurs types de p�riph�riques je te conseil une interface IPeripherique avec une class pour chacun. Apr�s tu mets les m�thodes d'acc�s aux infos � l'int�rieur.

Et encore : cela sous entend que tu acc�de � tous tes p�riph�riques de la m�me mani�re, ce qui n'est surement pas gagn� :
une souris et un clavier sont tous les deux consid�r�s comme des "p�riph�riques d'entr�es", mais, comme il n'y a aucune fonction commune � ces deux p�riph�riques (� moins de vouloir r�cup�rer la position de la souris quand une touche du clavier est enfonc�e / relach�e), la cr�ation d'une interface g�n�rqique susceptible de repr�senter "n'importe quel p�riph�rique" (m�me si ce n'est que "n'importe quel p�riph�rique d'entr�e") devient inaplicable en raison du LSP (Liskov Subsitution Principle ou principe de Substitution de Liskov)

Mais si tu as qu'un seul p�riph�rique et que tu ne comptes pas en ajouter autant faire une class simple sans trop s'emb�ter. Apr�s suivant si c'est pour toi ou pro y a plus ou moins de propret� � avoir, � toi de voir pour �a.

Pour cela, par contre, je suis tout � fait d'accord :Mes deux principes Xp pr�f�r�s sont KISS (Keep It Simple, Stupid) et YAGNI (You Ain't gonna Need It) : tant que tu n'as pas de garantie qu'il faudra apporter un "point de variation" quelque part, tu as int�r�t � ne pas essayer de le rajouter (le point de variation )

Ceci �tant dit, et pour quand m�me r�pondre � la question : ioctl et fd (file descriptor ) sont ils des obligations Puis-je subodorer que ton application sera d�velopp�e sur plusieurs niveau : une partie "m�tier" qui sera utilis�e sur un syst�me disposant de "peu de ressources" (embarqu� ou autre) et un syst�me de "consultation/ manipulation /gestion des donn�es / r�glages" qui pourrait -- lui -- �tre d�velopp� sur un PC "digne de ce nom"

Tu parles de "fonctions outils" et de tools : peut-on partir du principes que ces deux termes repr�sentent exactement la m�me chose Doit-on partir du principe qu'il s'agit de fonctions d�velopp�es en C (et non en C++)

Je sais que ces questions peuvent sembler surprenantes, mais les r�ponses que tu pourras donner sont clairement de nature � nous permettre de t'orienter au mieux en vue de trouver la solution :

1. on ne d�veloppe pas forc�ment de la m�me mani�re pour "embarqu�" que pour le "pc classique";
2. l'utilisation des file descriptor (si c'est bien ce que tu entends par fd) et de ioctl risque d'impliquer bien plus de travail que tu ne peux l'imaginer
3. l'int�gration de fonction C implique souvent la mise en place d'une s�rie de choses afin de garantir un minimum de s�curit� � leur emploi
4. la possibilit� d'avoir un syst�me "r�colteur" et un syst�me "utilisateur" des donn�es nous orientera vers une approche totalement diff�rente du probl�me que celle que nous aurions utilis�e si la r�colte et l'utilisation (finale) des donn�es avait �t� effectu�e sur le m�me pc
5. ...