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. ...