Discussion :

[mister3957]

Bonjour à tous,

Je fabrique un module dans une DLL, et je actuellement je cherche comment communiquer avec elle (échange de données, évènements etc.).

Dans cette DLL, les données sont organisées comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class ISet;
class CASet : public ISet
{
   std::vector<CA> m_vecDatas;
};
class CBSet : public ISet;
class CCSet : public ISet;

J'aimerai que le programme appelant puisse créer / utiliser des C[x]Set sans pour autant le contraindre à connaître leur structure interne ou savoir les manipuler.

J'ai pensé à créer et exporter des méthodes style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
long CreateASet();
long CreateAData(long lSet, int x, int y);
long SetAData(long lSet, long ldata, int x, int y);
etc.

où les différents long serait des pointeurs convertis en long et à l'intérieur des méthode, on reconvertirait ces longs en pointeurs.. comme des handles (si tant est que ça soit comme ça que fonctionnent les handles)

Est-ce que c'est comme ça qu'il faut faire ce genre de chose ?

Merci,
A bientôt

[jblecanard]

Salut

J'aimerai que le programme appelant puisse créer / utiliser des C[x]Set sans pour autant le contraindre à connaître leur structure interne

C'est tout l'intérêt du polymorphisme. Une contrainte de base est nécessaire cependant : que le programme appelant connaissent au moins l'interface des données manipulées.

Ton idée de factory (createXXX) est la bonne. Mais il faut que cette factory renvoie un pointeur sur l'interface (classe abstraite) des données manipulées.

ou comment les manipuler

Là, il va falloir que tu définisses "utiliser" sans "manipuler". Ca sent le gros bricolage dégueu à 100km... Le programme appelant ne peux pas utiliser la DLL sans rien connaître du tout. A partir du moment ou tu veux bien lui donner une factory, pourquoi ne pas vouloir exposer une interface ? ça n'a pas de sens.

Je n'ai pas compris ton trip avec les long, l'idée serait de manipuler les long dans l'appelant de sort qu'il ne sache pas que ce sont des pointeurs derrière ?

[mister3957]

En fait c'est que je m'y suis mal pris dès le départ je pense..

je suis en train de faire un logiciel cartographique. La DLL est le module cartographique (on lui donne un hWnd) et elle va s'afficher dans ce composant. Elle fournit aussi des méthodes genre "ZoomPlus", "ZoomMinus", "Moove(x, y)" etc.

Elle commence par afficher la carto via un générateur de tiles externe puis on peut configurer des entités supplémentaires à afficher, comme je sais pas, des radars, des tronçons de route particuliers, des zones industrielles etc. tout ça est configurable dans les fichiers de config de la carto.

Il y a trois types à afficher : les points, les lignes et les zones, que j'ai regroupé sous une interface avec une méthode "Fill" qui va se charger (selon les fichiers de configuration pour les requêtes etc.) et construire un modèle graphic situé dans l'interface, prêt à afficher.

Maintenant, j'aimerai bien que l'application appelante puisse donner à afficher ses données spécifiques sans pour autant connaître la construction / manipulation du modèle graphique..

le truc des longs c'était pour faire un peu comme dans plusieurs bibliothèques où l'on voit souvent ce genre de chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
hNode = xml.createNode("node1");
hChild = xml.createChild(hNode, "node2");
xmlSetText(hChild, "text");

Mais oui évidemment il manque une info dans mon cas, le type des entités.

Alors j'ai pensé à proposer une classe à l'application appelante pour manipuler les données de la carto, genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class CCartoImpl;
class CLandmarkSetImpl : CCartoSet;
class CLinearSetImpl : CCartoSet;
class CLandcoverSetImpl : CCartoSet;
// jusqu'ici, j'ai déjà, puis dans un fichier utilisable par le programme appelant
 
class CLandmarkSetImpl;
class EXPORT CLandmarkSet
{
public:
   CLandmarkSet(); //-> { Model.Register(this); } ( en tant que ICartoSet )
 
   void Add(int x, int y); //-> { m_pImpl->Add(SLandmark(x, y)); }
 
private:
   CLandmarkSetImpl* m_pImpl;
};
// pareil pour les linéaires et landcovers

Comme ça on suit le principe du pImpl Ideom

Et puis dans le model, différencier les entités internes, auxquelles il va falloir leur demander de se recharger en fonction de la navigation, et les entités externes, celles dont c'est le programme appelant qui gérera le contenu, mais ça je peux faire deux listes différentes de ICartoSet

Ça me paraît déjà plus propre, qu'est-ce que tu en penses ?

merci

[jblecanard]

Salut

Ok, l'idée des longs est se s'en servir comme d'un identifiant qui permet de distinguer chaque objet par la suite. L'avantage que je vois à ça que tu donnes pas la main à l'utilisateur de ta lib en ce qui concerne le cycle de vie des objets internes, ce qui est n'est pas idiot. C'est une idée assez bonne mais qui demande du boulot. Est ce que ça en vaut vraiment la peine dans ton cas ? Pas sûr.

J'avoue que vu ce que tu veux faire, tu as pas mal de choix. L'idée que tu proposes est tout à fait valable à mes yeux.

[mister3957]

Ouais, les longs comme identifiant était une mauvaise idée, car ça nécessiterai à chaque fois d'effectuer des recherches concernant la données visée à chaque manip.. Niveau perf ça serait une catastrophe.

Mieux vos un truc à base de pImpl Ideom, pour proposer une interface de manipulation des données sans pour autant contraindre le programme appelant à trop de dépendance..

Merci beaucoup pour cet échange