Comment expliquer l'injection de dépendance à un enfant de 5 ans? [fermé]

je vous fais une injection de dépendance pour les enfants de cinq ans.

lorsque vous sortez des choses du réfrigérateur pour vous-même, vous pouvez causer des problèmes. Tu pourrais laisser la porte ouverte, tu pourrais avoir quelque chose que maman ou papa ne veut pas que tu aies. Vous pourriez même chercher quelque chose que nous n'avons même pas ou qui a expiré.

ce que vous devriez faire est de déclarer un besoin, " j'ai besoin de quelque chose à boire avec le déjeuner," et puis nous Je m'assurerai que tu aies quelque chose quand tu t'assoiras pour manger.

et ça?

si vous avez une catégorie Employee et que cet employé a une catégorie Address , vous pouvez avoir la catégorie Employee définie comme suit:

class Employee {
    private Address address;

    // constructor 
    public Employee( Address newAddress ) {
        this.address = newAddress;
    }

    public Address getAddress() {
    return this.address;
    }
    public void setAddress( Address newAddress ) {
        this.address = newAddress;
    }
}

tout a l'air bien jusqu'à présent.

ce code montre une a-une relation entre l'employé et son adresse, c'est très bien.

maintenant, ce A-a relation créé une dépendance entre eux. Le problème vient du constructeur.

chaque fois que vous voulez créer une instance Employee vous avez besoin d'une instance Address :

 Address someAddress = ....
 Employee oscar = new Employee( someAddress ); 

travailler de cette façon devient problématique surtout quand vous voulez effectuer des tests unitaires.

Le principal problème vient quand vous avez besoin de tester un objet particulier, vous besoin de créer une instance d'un autre objet, et très probablement, vous devez créer une instance de encore autres objet pour le faire. La chaîne peut devenir ingérable.

pour éviter cela, vous pouvez changer le constructeur comme ceci:

  public Employee(){
  }

utilisant un constructeur no args.

alors vous pouvez définir l'adresse quand vous voulez:

 Address someAddress = ....
 Employee oscar = new Employee();
 oscar.setAddress( someAddress ); 

maintenant, cela peut être une traînée, si vous disposez de plusieurs attributs ou si les objets sont difficiles à créer.

pourtant, pensez à cela, disons, vous ajoutez l'attribut Department :

  class Employee {
      private Address address;
      private Department department;

  ....

si vous avez 300 employés, et tous ont besoin d'avoir le même département, et en plus ce même département doit être partagé entre certains autres objets (comme la liste de l'entreprise des départements, ou les rôles de chaque département ont etc), alors vous aurez un dur temps avec la visibilité de l'objet Department et de le partager à travers tout le réseau d'objets.

ce que le injection de dépendance est tout au sujet pour vous aider à, bien, "injecter" ces dépendances dans votre code. La plupart des frameworks vous permettent de le faire en spécifiant dans un fichier externe, quel objet doit être injecté.

Supposons un fichier de propriétés pour un injecteur fictif de dépendance:

  #mock employee
  employee.address = MockAddress.class
  employee.department = MockDepartment.class

  #production setup 
  employee.address = RealAddress.class
  employee.department = RealDepartment.class

vous définirez ce qu'il faut injecter pour un scénario donné.

ce que le cadre D'Injecteur de dépendances va faire est de définir les objets corrects pour vous, de sorte que vous n'avez pas à coder setAddress ou setDepartment . Cela se ferait soit par réflexion, soit par génération de code ou par d'autres techniques.

donc, la prochaine fois que vous avez besoin de tester la classe Employee vous pouvez injecter mock Address et Departments objets sans avoir à coder tout le set/get pour tout votre test. Encore mieux, vous pouvez injecter des objets real Address et Department dans le code de production, et avoir encore la confiance que votre code fonctionne comme testé.

C'est à peu près tout.

toujours Je ne pense pas que cette explication soit appropriée pour un enfant de 5 ans comme vous l'avez demandé.

j'espère que vous trouverez toujours utile.

quand on écrit une classe, il est naturel qu'elle utilise d'autres objets. Vous pouvez avoir une connexion de base de données, par exemple, ou certains autres services que vous utilisez. Ces autres objets (ou services) sont des dépendances. La façon la plus simple d'écrire le code est simplement de créer et d'utiliser ceux d'autres objets. Mais cela signifie que votre objet a une inflexible relation de ces dépendances: peu importe pourquoi vous appelez votre objet, il utilise les mêmes dépendances.

A une technique plus puissante est d'être capable de créer votre objet et de lui fournir des dépendances à utiliser. Ainsi, vous pouvez créer une connexion de base de données à utiliser, puis le passer à votre objet. De cette façon, vous pouvez créer votre objet avec dépendances différents à des moments différents, ce qui rend votre objet plus souple. C'est l'injection de dépendances, où vous "injectez" les dépendances dans l'objet.

BTW: dans le style de présentation moderne de l'utilisation de photos flickr pour illustrer des concepts, cela pourrait être illustré par le fait qu'un toxicomane se shoote avec de la drogue. Oh, attends, c'est une dépendance à l'injection... OK, désolé, mauvaise blague.

Je ne connais aucun tutoriel simplifié, mais je peux vous donner une version presque 25 250-mots-ou-moins:

avec l'injection de dépendances un objet ne configure pas ses propres composants sur la base de choses qu'il connaît déjà, mais l'objet est configuré par une logique de niveau supérieur, puis il appelle des composants dont il n'a pas de connaissance préalable intégrée. L'idée est de rendre l'objet plus d'un composant et à moins d'une demande, le déplacement des tâches de configuration à un niveau supérieur. Cela rend l'objet plus susceptibles d'être utiles dans l'avenir ou avec une configuration différente.

c'est mieux pour tester, c'est mieux quand vient le temps de réviser la demande. Une implémentation typique met la configuration en XML et utilise un framework pour charger dynamiquement les classes.

lorsque vous recevez une nouvelle Nintendo, vous pouvez juste utiliser les boutons et l'écran tactile pour jouer à des jeux.

mais à L'usine de Nintendo, ils ont besoin de savoir comment en assembler un.

Quand les gens intelligents à l'usine apporter une Nintendo DS, ce sera différent à l'intérieur, mais vous pourrez toujours savoir comment l'utiliser.