Discussion :

[coda_blank]

Généralement, on utilise une librairie dynamique en "sens unique", le code principal charge la librairie et appelle les fonctions paramétrées dont il a besoin

Mettons que l'on veuille injecter une dépendance dans cette lib (une classe du code principal par exemple), et donc inverser le contrôle, comment faut il s'y prendre ?

[6-MarViN]

Je ne pense pas que ce soit possible. Voir même pas du tout. En fait ça pue limite le hack ton truc.

[3DArchi]

Salut,
Je ne saisis pas le problème. Rien ne t'empêche de donner le contrôle à ta bibliothèque. Celle-ci contient une fonction/classe d'entrée (qui prend le contrôle) et ensuite à coup de DP prototype/fabrique tu implémentes ton IoC.

Code dll :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class dependency
{
public:
   virtual ~dependency()=0;
};
class application
{
public:
    application(dependency &); // demarrage
 
};

Code exe :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class my_dependency : public dependency
{
public:
    virtual ~my_dependency();
};
 
int main()
{
   my_dependency dep;
   application app(dep); // à partir de là, ta DLL prend le contrôle
   return 0;
}

[coda_blank]

Salut,
Je ne saisis pas le problème. Rien ne t'empêche de donner le contrôle à ta bibliothèque. Celle-ci contient une fonction/classe d'entrée (qui prend le contrôle) et ensuite à coup de DP prototype/fabrique tu implémentes ton IoC.

Code dll :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class dependency
{
public:
   virtual ~dependency()=0;
};
class application
{
public:
    application(dependency &); // demarrage
 
};

Code exe :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class my_dependency : public dependency
{
public:
    virtual ~my_dependency();
};
 
int main()
{
   my_dependency dep;
   application app(dep); // à partir de là, ta DLL prend le contrôle
   return 0;
}

Ok, jusque là pas de problème

maintenant mettons que dependency a besoin de plusieurs fichiers:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#include file1.hpp
#include file2.hpp
#include file3.hpp
 
class dependency
{
public:
   virtual ~dependency()=0;
};

et que chacun de ces fichiers a besoin d'autres fichiers, etc
au final on se retrouve avec une bonne portion de fichiers du code appellant à inclure dans la librairie
J'aimerais savoir comment éviter ça

[3DArchi]

Salut,
Déclaration anticipée ?
De toute façon si dependency dépend d'autres classes, alors ces classes doivent être des interfaces abstraites dont l'instance concrète est injectée à la construction. Peux tu préciser plus en détail ton exemple car sinon j'ai peur de ne pas forcément tout saisir.

[coda_blank]

Salut,
Déclaration anticipée ?
De toute façon si dependency dépend d'autres classes, alors ces classes doivent être des interfaces abstraites dont l'instance concrète est injectée à la construction. Peux tu préciser plus en détail ton exemple car sinon j'ai peur de ne pas forcément tout saisir.

ce qui me gêne c'est que dependency.hpp doive inclure d'autres fichiers .hpp, ce qui fait que l'on déporte une bonne partie du code appelant vers la librairie.
Code inutile pour celle-ci mais indispensable pour pour pouvoir injecter dependency
Je voulais savoir s'il y avait moyen de contourner cette injection de fichiers non nécessaires à la librairie