Interfaces d'une api

Bonsoir,
J'ai quelques questions concernant la créations d'interfaces pour créer une api, aux quelles je n'es pas trouvé de réponse malgré pas mal de recherches.

Je voudrais développer une librairie ayant plusieurs dépenses (lib externes). Pour simplifier l'utilisation de cette librairie avec d'autres programmes je voudrais que cette librairie soit autonome et inclue les dépendances. Je pense donc qu'il faut compiler mon programme sous forme de librairie static (.lib).

Pour utilisé ces lib par un autre programme il faut ajouter la lib dans l’éditeur de liens et inclure les headers (.h).

Mon problème est que les .h font des includes sur dépendances. Je crois qu'il faut donc je crée des interfaces pour les fonctions public utilisable de ma lib ?

Du coup je ne sais pas trop comment mis prendre. Ou doit je stocker les fichiers d'interfaces dans mon projet ? je n'est pas non plus trouver de documentation pour la création d'interfaces en c++. je sais uniquement que ce sont des déclaration virtuelle.

J'ai aussi trouvé ce bous de code dans un fichier d'interface:

Code:

---

1 2 3 4 5 6 7 8 9 10

#ifdef BUILDING_wke # define WKE_API __declspec(dllexport) #else # define WKE_API __declspec(dllimport) #endif   WKE_API void wkeInit(); WKE_API void wkeShutdown(); WKE_API void wkeUpdate();

---

Mais je ne vois pas trop ce que ça fait par rapport a ca:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

namespace wke { class IWebView { public: virtual void destroy() = 0;   virtual const char* name() const = 0; virtual void setName(const char* name) = 0;   virtual bool transparent() const = 0; virtual void setTransparent(bool transparent) = 0; } }

---

Désolé si je n'es pas été très claire, c'est assez abstrait pour moi.
Si vous avez des liens sur le sujet je suis preneur ;)

merci

Bonsoir,

je n'ai quasiment rien compris à ton charabia, mais quel est ton niveau en C++ ?

Ce qu'on apelle interface, c'est l'ensemble des items accessibles : les méthodes public (static) d'un objet (d'une class), les méthodes libres, types de données, ...
On apelle aussi interface une classe abstraite "pure", sans aucune implémentation

Si tu veux créer une lib, tu as 2 choix
- static (.lib, .a)
- dynamique (.dll à fournir, mais aussi .lib, .a à lier)

Les "fichiers d'interface" ne sont rien d'autre que les header. Tu les stockes où tu veux, ça n'a aucune incidence sur le code compilé, ils sont inclus uniquement et non compilés.

Citation:

---

Mon problème est que les .h font des includes sur dépendances. Je crois qu'il faut donc je crée des interfaces pour les fonctions public utilisable de ma lib ?

---

Pourrais-tu traduire ce passage ?

Code:

---

1 2 3 4 5 6 7 8 9 10

#ifdef BUILDING_wke # define WKE_API __declspec(dllexport) #else # define WKE_API __declspec(dllimport) #endif   WKE_API void wkeInit(); WKE_API void wkeShutdown(); WKE_API void wkeUpdate();

---

Ca c'est peut-être la déclaration de fonctions d'une API C. Comme c'est écrit DLLexport/import, c'est du dynamique et exporté dans une dll.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

namespace wke { class IWebView { public: virtual void destroy() = 0;   virtual const char* name() const = 0; virtual void setName(const char* name) = 0;   virtual bool transparent() const = 0; virtual void setTransparent(bool transparent) = 0; } }

---

Ca c'est une classe abstraite (aux erreurs de ; et } près) "pure", sans aucune implémentation donc une interface.

Bonjour et merci pour la réponse.

Citation:

---

Envoyé par Bousk

je n'ai quasiment rien compris à ton charabia, mais quel est ton niveau en C++ ?

---

On va dire que suis pas encore très doué je l'avoue :)

Citation:

---

Envoyé par Bousk

Citation:

---

Mon problème est que les .h font des includes sur dépendances. Je crois qu'il faut donc je crée des interfaces pour les fonctions public utilisable de ma lib ?

---

Pourrais-tu traduire ce passage ?

---

Je vais prendre un exemple je pense que ca sera plus simple.
Disons Que je developpe une class A qui pour fonctionné a besoin d'une class B provenant d'un librairie externe a mon projet ( fichier header .h + .lib)
le header de ma class ressemblera donc a quelque chose du style:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

/**  * a.h  */ #include <B.h>   class A { public: A(void); ~A(void); void method1(void); void method2(void); private int method3(B* b); };

---

si je compile un .lib avec cette class si je veu l'utiliser pour un autre projet je devrais aussi ajouter la lib B a ce projet en plus de la A car le header a.h appelle directement la class B dans ses include.

je ne sais pas trop comment faire pour éliminer cette dépendance, je pensais qui fallait crée un deuxième a.h contenant l'interface de la class a c'est a dire uniquement les methods public et sans faire les include que je pourrait utilisé pour un autre projet. Je doit surement me tromper :aie:.

j'espère avoir été un peu plus claire sur mon problème
merci

Si A a besoin de B, elle doit l'inclure.

Effectivement si ta lib utilise une autre lib, le programme final doit lier toutes les libs nécessaires.
Il existe peut-être un moyen d'inclure une lib dans une autre mais je n'ai jamais réellement cherché ce procédé.
Peut-être faut-il juste posséder les différents code-sources et les compiler au sein d'une seul et même lib. Peut-être une autre astuce.

Le mieux reste à mon avis que tu crées un projet fonctionnel puis seulement que tu essayes de le décomposer en lib.

Merci pour ta réponse.
En faite, il y a quelques jours, je suis tombé par hasard sur une librairie qui correspondait a un de mais besoin:
http://sourceforge.net/projects/wke/

Cette api permet d'utiliser webkit dans une appli en c++ (dont un moteur 3d), elle marche bien mais malheureusement est inconnue et n'a pas de documentation ni de forum support.

Elle ma un peu intrigué car pour l'utiliser, il suffi de fait un include sur un .h , qui est en faite une interface et de linker un .lib et ca marche, on a pas besoin de récupérer le sdk ou les source de webkit et les linker au projet.

dans les sources, il y a bien le code source de webkit.

En refouillant dans ses sources je crois que je viens de comprendre comment il procède. Ça me parait quant même être un peu du bricolage :P.

En faite il a une classe principale (CWebView) qui hérite de son interface (IWebView), pour instancié CWebView il a écrit une fonction (wkeCreateWebView()) dans un fichier cpp (qui lui fait les include sur les dépendances) hors d'un objet.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

//dans l'interface typedef wke::IWebView* wkeWebView;   //dans le fichier cpp wkeWebView wkeCreateWebView() { wke::CWebView* webView = new wke::CWebView; s_webViews.append(webView); return webView; }

---

Et après on peut utilisé les fonction de l'objet wke::CWebView défini dans l'interface, enfin je crois a tester :calim2:

Apres plusieur question me viennent a l'esprit:

Pour quoi défini la plus part de c'est fonction hors d'une class et ne pas avoir fait une classe regroupant les fonction de son api puisque quelles renvoi des type déclaré dans son interface.

Je ne sait pas trop s'il y'a moyen de faire plus simple et si cela nécessite le code source des dépendances ou que ça marche avec les .lib

Il n'y aurait pas un design pattern pour décrire cette méthode de développement ?

Ce que tu montres ressemble vaguement de loin à une factory, mais ça n'a aucun rapport direct avec une interface ou une lib.

Citation:

---

Envoyé par Bousk

Ce que tu montres ressemble vaguement de loin à une factory, mais ça n'a aucun rapport direct avec une interface ou une lib.

---

si c'est le

Code:

---

s_webViews.append(webView);

---

Qui te fait panser a cela, ce n'est pas le code que j'ai voulu pointer ici, mais plus l’instanciation d'une class héritant d'une interface, dans une fonction renvoyant un objet avec le type de l'interface.

Bonjour,

Je te conseil d'étudier le principe d'une interface.

Le but est simple admettons que j'ai un programme qui prend des modules de gestion de protocole réseau.

Je déclare un interface monInterface, pcq je ne peux pas deviner le nom des classes créé tout au long de la vie de mon programme et j'ai pas envie, quand j'ajoute un nouveau module de l'implémenter à mon programme.

C'est la que l'interface rentre en jeu, elle défini un fonctionnement précis mais non implémenté.

Comme ça dans le noyau de ton programme tu manipule des pointeurs de type monInterface et quand tu ajoute un module genre moduleFtp qui dépend de monInterface, ton programme exécutera ses méthodes sans savoir qui il est et ce qu'il fait.

Et oui quand tu manipule un pointeur de type interface, tu exécute les méthode implémenter dans ta classe fille car c'est la seule implémentation qui existe pour l'objet que tu manipule à l'instant T.

Je ne suis pas sure d'être super clair, donc j'attend tes retours.

Citation:

---

Envoyé par jouana

Bonjour,

Je te conseil d'étudier le principe d'une interface.

Le but est simple admettons que j'ai un programme qui prend des modules de gestion de protocole réseau.

Je déclare un interface monInterface, pcq je ne peux pas deviner le nom des classes créé tout au long de la vie de mon programme et j'ai pas envie, quand j'ajoute un nouveau module de l'implémenter à mon programme.

C'est la que l'interface rentre en jeu, elle défini un fonctionnement précis mais non implémenté.

Comme ça dans le noyau de ton programme tu manipule des pointeurs de type monInterface et quand tu ajoute un module genre moduleFtp qui dépend de monInterface, ton programme exécutera ses méthodes sans savoir qui il est et ce qu'il fait.

Et oui quand tu manipule un pointeur de type interface, tu exécute les méthode implémenter dans ta classe fille car c'est la seule implémentation qui existe pour l'objet que tu manipule à l'instant T.

Je ne suis pas sure d'être super clair, donc j'attend tes retours.

---

Oui je comprend et je connais cette utilisation des interfaces.
Je parle d'une utilisation un peu différente qui est utilisé par exemple par le sdk Physx qui fourni les interfaces, les .lib et les dll qui permet de l'utiliser sans ce soucier des dépendances.

Citation:

---

Envoyé par lpa

l’instanciation d'une class héritant d'une interface, dans une fonction renvoyant un objet avec le type de l'interface.

---

Ca c'est du polymorphisme tout ce qu'il y a de plus classique.

Citation:

---

Je parle d'une utilisation un peu différente qui est utilisé par exemple par le sdk Physx qui fourni les interfaces, les .lib et les dll qui permet de l'utiliser sans ce soucier des dépendances.

---

PhysX est une librairie, c'est tout. Elle fournit dll, header et lib pour son utilisation et est indépendante.

Plus ça va, moins je comprends ta "question" par contre.

Je comprend pas trop ton soucis en faite

Citation:

---

Envoyé par Ipa
mais plus l’instanciation d'une class héritant d'une interface, dans une fonction renvoyant un objet avec le type de l'interface

---

Ta lib a une classe A qui hérite d'un interface.

tu manipule la classe A comme si c'était une interface.

Ensuite tu peux avoir dans ta lib un fonction qui retourne un objet de type interface et qui instancie un objet A ou B.

La dessus je rejoins Bousk c'est de la factory.

Et après ils s’en foutent des dépendances tout est dans la ou les lib.

Citation:

---

Envoyé par jouana

Je comprend pas trop ton soucis en faite



Ta lib a une classe A qui hérite d'un interface.

tu manipule la classe A comme si c'était une interface.

Ensuite tu peux avoir dans ta lib un fonction qui retourne un objet de type interface et qui instancie un objet A ou B.

La dessus je rejoins Bousk c'est de la factory.

Et après ils s’en foutent des dépendances tout est dans la ou les lib.

---

Tu viens de réponde a ma question, je ne voyais pas le pattern factory fonctionner de cette manière, ne m'y ayant jamais intéressé.
Je pensait que ça créait des objets et que ça les stockais uniquement, je ne savais pas que ça permettais de supprimer les dépendances.
merci :ccool:

Citation:

---

Envoyé par lpa

Je pensait que ça créait des objets et que ça les stockais uniquement, je ne savais pas que ça permettais de supprimer les dépendances.

---

Parce que c'est son but...
Une factory, comme son nom l'indique, crée un objet.
Elle ne le stocke pas forcément.
Et en aucun cas elle n'agit sur les dépendances en tous cas. Et si c'est le cas (par un quelconque procédé complètement indépendant de la factory en elle-même), ce n'est clairement pas son objectif principal mais du bonus ajouté.

Citation:

---

Envoyé par jouana

Et après ils s’en foutent des dépendances tout est dans la ou les lib.

---

Se que je voulais dire par la c'est que les lib fournis contiennent toutes les dépendances nécessaire à sont bon fonctionnement.

Il ne faut pas confondre ta solution ou ton projet avec le développement en lui même.

Après j'ai l'impressions qu'on a un peu de mal à tous s'accorder :)

Mais si tu as la réponse que tu recherche t'en mieux pour toi, ça serait bien de faire un ti compte rendu à la fin du post, histoire de bien aider les gens qui passeront par la :)

Apres mettre renseigné un peu plus sur le pattern Factory, L'exemple que jai cité plus haut n'est pas vraiment du factory pure, on dirait un mélange entre l'abstract factory et le factory.
car ont retrouve ce point de l'abstract factory:

Citation:

---

Le code client n'a aucune connaissance du type concret, et ne nécessite donc aucun fichier header ou déclaration de classe requis [...] Les objets concrets sont en effet créés par la fabrique, et le code client ne les manipule qu'avec leur interface abstraite.

---

citation: http://fr.wikipedia.org/wiki/Fabriqu...de_conception)

Mais d'un autre coté on a pas le fait d'avoir plusieurs fabrique concrète héritant d'une fabrique abstraite ...

Encore une fois, ce que tu cites ce n'est rien de plus que du polymorphisme.
Et il n'est nullement besoin de factory pour créer et manipuler des objets polymorphes.

Je rejoins Bousk je pense que tu mélange un petit peu tout la.