Hello les amis,
 
Quelqu'un peut-il expliquer le design pattern IoC (injection of control) ?
 
De même la différence entre l'injection de contrôle et l'injection de dépendance ?
 
   

IOC Inversion of control

Un très bon article :

http://dotnetslackers.com/articles [...] Part1.aspx

 
C'est le topic java. Donc j'aimerai bien des exemple java pas .NET, comme avec spring & co.
 
oust les crosofts

Hm. Peu importe (ou presque) le langage lorsque la discussion porte sur les design patterns.

Ca sert à faciliter le remplacement de services par d'autres services, et en particulier par des Mocks pour le test.

Exemple: tu écris un client qui appelle deux services quelconques

public class ZeClient {
   private DbManagerInterface dbMgr;
   private ExternalServiceInterface extService;
}

Sans IoC, ta classe client va instancier elle-même dbMgr et extService (via des Factory par ex).
Avec IoC, l'instanciation se fait en-dehors de ta classe.
Celle-ci ne va que conserver les instances existantes déjà créées. On injecte ces instances via le constructeur ou via des setters

public class ZeClient {
   private DbManagerInterface dbMgr;
   private ExternalServiceInterface extService;
 
  public ZeClient(DbManagerInterface dbMgr, ExternalServiceInterface extSrv){
      this.dbMg= dbMgr;
      this.extService = extSrv;
  }
 
  public void setExtService(ExternalServiceInterface extSrv) {
      this.extSrv = extSrv;
  }
 
  public void setDbMgr(DbManagerInterface dbMgr) {
      this.dbMgr = dbMgr;
  }
}

Il faut imaginer que dans une vraie application, ma classe ZeClient peut avoir facilement 5 ou 6 services (voire bcp plus), qui eux-mêmes appellent plusieurs services.
Du coup, dans une classe de test, quand j'instancie ZeClient, j'instancie au préalable tout l'arbre de dépendances des services dont il dépend potentiellement (même si dans mon test, je n'en utilise en réalité qu'un seul). Ca a deux inconvénients:
1. ZeClient embarque avec lui tous les services qu'il instancie. Sauf à modifier un fichier de mapping interface<->implémentation, on ne peut pas changer les services dbMgr et extService sans avoir à modifier le code de ZeClient.
2. Pour un test qui se veut unitaire de ZeClient, je suis obligé de créer tout l'univers: certains services, avant d'être utilisables, peuvent être pénibles à configurer, par ex, pour une base de donnée et un service externe, il faut préalablement que la base et le service en question existent sur le réseau et répondent correctement. Pour peu que chacun des services que ZeClient utilise appelle lui-même d'autres services, il faut tout configurer et il faut que tout fonctionne avant même de pouvoir lancer le moindre test. On ne fait plus de l'unitaire, mais de l'intégration, alors qu'on voudrait pouvoir juste les mocker pour retourner une valeur donnée quelconque.
Avec IoC, parce que ZeClient n'instancie plus rien lui-même, on peut créer les mocks, les instancier soi-même, et les injecter via le constructeur ou les setteurs.

Ok, donc IoC sert principalement à instancier des objets et les initialiser dans les attributs d'une classe. On peut aussi faire des Mocks pour les tests grace à IoC.
Si je dis ca en entretien, ca risque de faire léger.
 
Et sinon quelle différence avec Injection de Dépendance ?

 
Cet exemple explique clairement la différence entre ioc et injection de dépendances, si je l'ai donné c'est parce qu’il te permettra à coup sûr de la comprendre sans trop de prise de tête (15-20 minutes de lecture).

Si c'est juste pour passer un entretien, oublie, c'est pas comme ça que tu vas faire illusion. Ca sert à rien de tenter de faire croire qu'on sait, au contraire, ça fait particulièrement mauvais effet. D'ailleurs, ta question montre que tu n'as pas compris grand chose...

L'injection de dépendance est un des pattern pour implémenter l'inversion de contrôle.  

Bon je crois que j'ai pijé.

IoC = Inversion de contrôle = principe d'Hollywood "Ne m'appelez pas, c'est moi qui vous appelle"
En général c'est l'application qui appelle le framework, et bien dans IoC c'est le framework qui appelle l'application. Les rôles sont inversés.
C'est Spring qui se charge de la mise en relation des objets, et non les objets qui utilisent le framework pour se mettre en relation.

Injection de dépendance = découplage des objets
A utilise (dépend de) B -> couplage fort entre A et B
B est injecté dans A -> couplage faible entre A et B
Dans l'injection de dépendance Spring, c'est le framework qui s'occupe d'instancier B et de l'injecter dans A.