Qu'est-ce que l'injection de dépendance?

Question

Il y a eu plusieurs questions déjà posté les questions spécifiques au sujet de l'injection de dépendance, comme lorsque l'utiliser et ce qu'cadres sont là pour cela. Cependant,

Qu'est-ce que l'injection de dépendance et quand/pourquoi devrait ou ne devrait-il pas être utilisé?

Answer 1

La meilleure définition que j'ai trouvé pour l'instant est un par James Shore:

"L'Injection de dépendance" est à 25 dollars terme pour un 5 cent concept. [...] L'injection de dépendance, c'est donner une objet de ses variables d'instance. [...].

Il y a un article de Martin Fowler qui peut s'avérer utile aussi.

L'injection de dépendance est essentiellement de fournir les objets qu'un objet doit (et ses dépendances) au lieu de l'avoir à les construire lui-même. C'est une technique très utile pour les tests, car il permet de dépendances se moque de lui ou écrasé.

Les dépendances peuvent être injectés dans les objets par de nombreux moyens(Constructeur d'injection Injection par mutateur). On peut même utiliser spécialisés injection de dépendance des cadres de l'e.g Spring Framework) pour le faire, mais ils ne sont certainement pas nécessaires. Vous n'avez pas besoin de ces cadres d'avoir l'injection de dépendance. L'instanciation et les objets de passage (dépendances) explicite est aussi bien une injection, l'injection par un cadre.

Answer 2

En gros, au lieu d'avoir des objets de la création d'une dépendance ou de poser une usine de l'objet pour en faire un pour eux, vous passez les dépendances nécessaires dans le constructeur ou via des accesseurs de propriété, et de vous rendre quelqu'un d'autre problème (un objet plus haut que le graphe de dépendance, ou une dépendance de l'injecteur qui construit le graphe de dépendance). Une dépendance que j'utilise ici est tout autre objet à l'objet courant doit contenir une référence.

L'un des principaux avantages de l'injection de dépendance est qu'il peut faire des tests beaucoup plus facile. Supposons que vous avez un objet qui, dans son constructeur fait quelque chose comme:

public SomeClass() {
    myObject = Factory.getObject();
}

Cela peut être gênant quand tout ce que vous voulez faire est de lancer quelques tests unitaires sur SomeClass, surtout si monobjet est quelque chose qui ne complexe de disque ou réseau d'accès. Alors maintenant, vous êtes à la recherche à se moquant de myObject mais aussi d'une certaine manière l'interception de l'usine d'appel. Dur. Au lieu de cela, passer de l'objet comme un argument du constructeur. Maintenant que vous avez déplacé le problème ailleurs, mais le test peut devenir beaucoup plus facile. Il suffit de faire une mannequin myObject et le passer en. Le constructeur serait maintenant regarder un peu comme:

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

La plupart des gens peuvent probablement les autres problèmes qui peuvent survenir lorsque vous n'utilisez pas l'injection de dépendance alors que les tests (comme des classes qui ne trop de travail dans leurs constructeurs, etc.) Les plus de ce sont des choses que j'ai ramassé sur le Google Blog de Tests, pour être parfaitement honnête...

Answer 3

J'ai trouvé ce drôle d'Exemple, en termes de perte de couplage:

Toute application est composée de nombreux objets qui collaborent les uns avec les autres pour effectuer quelques trucs utiles. Traditionnellement, chaque objet est responsable de l'obtention de ses propres références pour les objets dépendants (dépendances) il collaborer avec. Cela conduit à fortement couplé classes et dur-à-code d'essai.

Par exemple,considérons un Car objet.

Un Car dépend de Roues, Moteur, Carburant, Batterie, etc à exécuter. Traditionnellement, nous avons définir la marque de ces objets qui en dépendent ainsi que la définition de l' Car objet.

Sans Injection de Dépendance (DI) :

class Car{
  private Wheel wh= new NepaliRubberWheel();
  private Battery bt= new ExcideBattery();
  //rest
}

Ici, l' Car objet est chargé de créer les objets qui en dépendent.

Que faire si nous voulons changer le type de son objet dépendant - dire Wheel - après la première NepaliRubberWheel()crevaisons? Nous avons besoin de recréer l'objet Voiture avec sa nouvelle dépendance dire ChineseRubberWheel(), mais seulement l' Car fabricant peut le faire.

Alors que l' Dependency Injection nous fait pour ...?

Lors de l'utilisation de l'Injection de Dépendance, les objets sont donné leurs dépendances au moment de l'exécution plutôt que de moment de la compilation (voiture le temps de fabrication). De sorte que nous pouvons maintenant modifier le Wheel chaque fois que nous voulons. Ici, l' Dependency (Wheel) peut être injecté en Car au moment de l'exécution.

Après l'utilisation de DI:

class Car{
  private Wheel wh= [Inject an Instance of Wheel at runtime]
  private Battery bt= [Inject an Instance of Battery at runtime]
}

Source: compréhension-injection de dépendance

Answer 4

L'Injection de dépendance est une pratique où les objets sont conçus d'une manière où ils reçoivent des instances des objets à partir d'autres morceaux de code, plutôt que de construire à l'interne. Cela signifie que tout objet implémentant l'interface qui est requis par l'objet peuvent être remplacées sans modifier le code, ce qui simplifie les tests, et améliore le découplage.

Par exemple, tenir compte de ces clases:

public class PersonService {
  public void addManager( Person employee, Person newManager ) { ... }
  public void removeManager( Person employee, Person oldManager ) { ... }
  public Group getGroupByManager( Person manager ) { ... }
}

public class GroupMembershipService() {
  public void addPersonToGroup( Person person, Group group ) { ... }
  public void removePersonFromGroup( Person person, Group group ) { ... }
}

Dans cet exemple, la mise en œuvre de l' PersonService::addManager et PersonService::removeManager auraient besoin d'une instance de la GroupMembershipService afin de faire son travail. Sans l'Injection de Dépendance, la façon traditionnelle de faire ce serait pour instancier un nouveau GroupMembershipService dans le constructeur de l' PersonService et l'utilisation de cette instance de l'attribut dans les deux fonctions. Toutefois, si le constructeur de GroupMembershipService a plusieurs choses qu'il exige, ou, pire encore, il y a quelques initialisation des "poseurs" qui ont besoin d'être appelée sur l' GroupMembershipService, le code se développe très rapidement, et l' PersonService maintenant ne dépend pas seulement de l' GroupMembershipService , mais aussi de tout ce qu' GroupMembershipService dépend. En outre, le lien pour le GroupMembershipService est codé en dur dans l' PersonService ce qui signifie que vous ne pouvez pas "dummy" GroupMembershipService des fins de test ou d'utiliser un modèle de stratégie dans les différentes parties de votre application.

Avec l'Injection de Dépendance, au lieu de l'instanciation de la GroupMembershipService au sein de votre PersonService, youd soit passer à l' PersonService constructeur, ou bien ajouter une Propriété (getter et setter) pour définir une instance locale. Cela signifie que votre PersonService n'a plus à s'inquiéter sur la façon de créer un GroupMembershipService, il à juste à accepte le de ceux qu'il a donné, et travaille avec eux. Cela signifie aussi que tout ce qui est une sous-classe de GroupMembershipService, ou met en œuvre l' GroupMembershipService interface peut être "injecté" dans l' PersonService, et l' PersonService n'a pas besoin de savoir le changement.

Answer 5

L'on a accepté la réponse est un bon un, mais je voudrais ajouter à ce que DI est très semblable à la classique en évitant de codé en dur constantes dans le code.

Lorsque vous utilisez une constante comme un nom de base de données que vous avais passer rapidement de l'intérieur du code à son fichier de config et passer une variable contenant la valeur à l'endroit où elle est nécessaire. La raison pour cela est que ces constantes généralement changent plus fréquemment que le reste du code. Par exemple, si vous souhaitez tester le code dans une base de données de test.

DI est analogue à présent dans le monde de la programmation Orientée Objet. Les valeurs de là, au lieu de constantes littérales sont l'ensemble des objets - mais la raison pour déplacer le code de création de la classe de code est similaire, les objets changent plus fréquemment ensuite le code qui les utilise. Un cas important où un tel changement est nécessaire que les tests.