Injection de dépendance et librairie dynamique (dll ou so)

Version imprimable

16/09/2011, 21h10
coda_blank

Injection de dépendance et librairie dynamique (dll ou so)

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 ?
16/09/2011, 22h49
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.

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:

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:

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; }

Citation:
Envoyé par 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:

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:

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:

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

17/09/2011, 23h40
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.
19/09/2011, 12h44
coda_blank

Citation:

Envoyé par 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.

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

Salut,
Si elle utilise d'autres header, c'est que la bibliothèque en a besoin. Normalement, on devrait avoir quelque chose ressemblant à ça

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class interface
{
public:
    void something(){do_something();}
    virtual interface();
private:
     virtual void do_something()=0;
};
class dependency
{
   dependency(interface&);
public:
   virtual ~dependency()=0;
};
class application
{
public:
    application(dependency &); // demarrage
 
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class my_interface : public interface
{
public:
    virtual ~my_interface();
};
 
class my_dependency : public dependency
{
public:
    my_dependency(my_interface&intf):dependency(intf){}
    virtual ~my_dependency();
};
 
int main()
{
   my_interface intf;
   my_dependency dep(intf);
   application app(dep); // à partir de là, ta DLL prend le contrôle
   return 0;
}

La dépendance peut être injecté non pas à la construction mais éventuellement avec un DP Fabrique :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
class interface
{
public:
    void something(){do_something();}
    virtual interface();
private:
     virtual void do_something()=0;
};
class dependency
{
   dependency();
   void int_needed()
   {
         interface& intf = getInterface();
   }
public:
   virtual ~dependency()=0;
   virtual interface&getInterface()=0;
};
class application
{
public:
    application(dependency &dep); // demarrage
 
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
class my_interface : public interface
{
public:
    virtual ~my_interface();
};
 
class my_dependency : public dependency
{
public:
    virtual ~my_dependency();
private:
     virtual interface&getInterface()
     {
           return intf;
     }
     my_interface intf;
};
 
int main()
{
   my_dependency dep;
   application app(dep); // à partir de là, ta DLL prend le contrôle
   return 0;
}

Bref, si une dependency a elle même des dépendances, il faut définir les interfaces abstraites sur laquelle elle s'appuie et l'implémenter côté application. Si côté application my_dependency a des besoins transparents pour la classe de base, alors c'est dans la construction de my_dependency dans l'applicatif qu'il faut injecter ces dépendances.

Tu peux construire un petit exemple de ce qui te pose problème car là j'ai l'impression d'avoir quelque chose qui m'échappe.

Tu es bien d'accord que :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class my_interface : public interface { public: virtual ~my_interface(); }; #include "my_interface.h" class my_dependency : public dependency { public: virtual ~my_dependency(); private: virtual interface&getInterface() { return intf; } my_interface intf; };
et que donc :
Code:

1 2 3 4 5 6 7 8 9 #include "dependency.h" int main() { my_dependency dep; application app(dep); // à partir de là, ta DLL prend le contrôle return 0; }
question déploiement on aura ainsi côté appelant :

my_interface.h
dependency.h

et côté librairie :

my_interface.h
dependency.h

si l'on opère des changements sur my_interface.h dans le code appelant, il faudra les répercuter dans la lib en remplaçant le fichier et en recompilant la lib; or la librairie ne s'intéresse qu'à dependency.h, pourquoi lui imposer my_interface.h ?

ce qui m'intéresse donc c'est de savoir s'il y a moyen de n'inclure que dependency.h dans la lib même si dependency.h dépend d'autres .h

19/09/2011, 20h37
3DArchi
Non.
Côté DLL, on a
- dependency.h qui défini dependency et qui inclut :
- interface.h qui défini interface.
Côté EXE, on a :
- my_dependency.h qui défini my_dependency qui hérite et implémente dependency et :
- my_interface.h qui défini my_interface qui hérite et implémente interface.
Si my_interface évolue, c'est de façon totalement transparente pour dependency (et dependency.h). Mais peut être pas pour my_dependency (et my_dependency.h). Bref, seul ce qui est dans l'exécutable est impacté.

A l'inverse, si interface évolue, ça peut avoir un impact sur dependency (et dependency.h) et certainement sur my_interface (et my_interface.h). Mais dans ce sens cela ne me choque pas.

Derrière l'injection de dépendance et l'IoC il y a le socle du DIP : Dependency Inversion Principle.