Discussion :

[rgamor]

Bonjour,

J'aimerais faire une API en C++ qui permet d'utiliser une carte de développement via une communication type socket.
D'un point de vue UML on aurait tout en haut la classe "API" qui se divise en deux pour donner "APIserveur" et "APIclient".
Ces deux classes doivent avoir des classes sous-jacentes en communs n'est-ce-pas? par exemple une classe "Bouton" avec pour méthodes setEtat qui permet à la parti APIserveur de mettre à jour la valeur et getEtat pour la lire à partir de APIclient, c'est comment ça que ça se fait en général ou je fait fausse route?

Mon problème est: puisque la classe "Bouton" est commune aux deux parties (serveur et client) la méthode setEtat n'a aucun sens vis à vis de la partie client et inversement, comment rendre ces méthodes "invisibles" en fonction de la partie sur laquelle le développeur travaille? Faut-il créer une classe "Bouton" pour la partie client et une différente pour la partie serveur dans ce cas il faut maintenir deux classes au lieu d'une seule?

Si quelqu'un se souvient d'une API avec laquelle il a travaillé qui ressemble à peu prêt je serais ravi de l'étudier.

[dragonjoker59]

J'aimerais savoir ce que tu appelles une API ?
De plus, j'ai l'impression que tu as l'intention de mélanger le code métier et le code de ton interface graphique, ce qui est généralement une mauvaise idée.
Il vaut généralement mieux bien séparer les 2, afin de pouvoir changer d'IHM sans toucher au métier.

[rgamor]

En fait l'API permettra de faire abstraction de la couche de communication, et fournissant les mêmes modèles aux deux parties.
A partir du APIclient on peut imaginer qu'elle sera soit utiliser pour faire une IHM ou alors dans un code qui exécutera la logique.
Et puis du côté serveur, l'APIserveur servira à fournir les infos et réceptionner les commandes de la partie client ou alors implémenter un simulateur.

[bacelar]

Faut que ça murisse, votre histoire d'API.

Il faut concevoir une API sous forme de paradigmes puis l'implémenter.

Or, vous vous attachez à des problématiques qui ne devraient pas avoir lieu d'être à cette étape de la conception.

Si les paradigmes coté serveur sont les mêmes que coté clients, c'est qu'on n'est plus sur une approche peer2peer que client-serveur.
Le peer2peer et le client-serveur n'ont que peu de points communs.