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.