Comment expliquer l'injection de dépendances à un enfant de 5 ans ?

Question

Quelle est une bonne façon d'expliquer injection de dépendances ?

J'ai trouvé plusieurs tutoriels sur Google, mais aucun d'entre eux ne suppose que le lecteur est un débutant en Java. Comment expliqueriez-vous cela à un novice ?

Answer 1

Je vous donne l'injection de dépendance pour les enfants de 5 ans.

Lorsque vous allez chercher des choses dans le réfrigérateur pour vous-même, vous pouvez causer des problèmes. Tu peux laisser la porte ouverte, tu peux prendre quelque chose que maman ou papa ne veut pas que tu aies. Tu peux même chercher quelque chose que nous n'avons pas ou qui est périmé.

Ce que vous devez faire, c'est exprimer un besoin : "J'ai besoin de quelque chose à boire avec le déjeuner", et nous nous assurerons que vous avez quelque chose lorsque vous vous asseyez pour manger.

Answer 2

Et ça ?

Si vous avez une classe Employee et cet employé a un Address vous pouvez avoir le 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 semble correct jusqu'à présent.

Ce code montre un HAS-A relation entre l'employé et son adresse, c'est bien.

Maintenant, cette HAS-A Cette relation a créé une dépendance entre eux. Le problème vient du constructeur.

Chaque fois que vous voulez créer un Employee Vous avez besoin d'un Address instance :

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

Travailler de cette façon devient problématique notamment lorsque vous voulez effectuer des tests unitaires.

Le principal problème survient lorsque vous devez tester un objet particulier, vous devez créer une instance d'un autre objet, et très probablement vous devez créer une instance d'un autre objet. autre pour ce faire. La chaîne peut devenir ingérable.

Pour éviter cela, vous pouvez modifier le constructeur comme suit :

  public Employee(){
  }

Utilisation d'un constructeur sans argument.

Vous pouvez alors définir l'adresse quand vous le souhaitez :

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

Maintenant, cela peut être un frein, si vous avez plusieurs attributs ou si les objets sont difficiles à créer.

Pourtant, pensez à ceci, disons que vous ajoutez la Department attribut :

  class Employee {
      private Address address;
      private Department department;

  ....

Si vous avez 300 employés, et qu'ils ont tous besoin d'avoir la même et que ce même département doit être partagé par d'autres objets (comme la liste des départements de l'entreprise, ou les rôles de chaque département, etc. Department et de le partager à travers tout le réseau d'objets.

Qu'est-ce que le Injection de dépendances est tout ce qu'il faut pour vous aider à, eh bien, "injecter" ces dépendances dans votre code. La plupart des frameworks vous permettent de faire cela en spécifiant dans un fichier externe, quel objet doit être injecté.

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

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

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

Vous allez définir ce qu'il faut injecter pour un scénario donné.

Ce que le cadre de l'injecteur de dépendances fera, c'est de définir les objets corrects pour vous, de sorte que vous n'avez pas à coder setAddress o setDepartment . Cela se fait soit par réflexion, soit par génération de code ou par d'autres techniques.

Ainsi, la prochaine fois que vous aurez besoin de tester l'option Employee vous pouvez injecter des objets fantaisie Address y Departments sans avoir à coder tous les set/get pour tous vos tests. Encore mieux, vous pouvez injecter réel Address y Department dans le code de production, tout en ayant la certitude que votre code fonctionne comme prévu.

C'est à peu près tout.

Néanmoins, je ne pense pas que cette explication soit adaptée à un enfant de 5 ans comme vous l'avez demandé.

J'espère que vous le trouverez toujours utile.

Answer 3

Lorsqu'on écrit une classe, il est naturel qu'elle utilise d'autres objets. Vous pouvez avoir une connexion à une base de données, par exemple, ou un autre service 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 ces autres objets. Mais cela signifie que votre objet a une relation inflexible avec ces dépendances : peu importe pourquoi vous invoquez votre objet, il utilise les mêmes dépendances.

Une technique plus puissante consiste à pouvoir créer votre objet et à lui fournir des dépendances à utiliser. Ainsi, vous pouvez créer une connexion de base de données à utiliser, puis la fournir à votre objet. De cette façon, vous pouvez créer votre objet avec différentes dépendances à différents moments, ce qui rend votre objet plus flexible. C'est l'injection de dépendances, où vous "injectez" les dépendances dans l'objet.

BTW : Dans le style de présentation moderne qui consiste à utiliser des photos flickr pour illustrer des concepts, on pourrait illustrer cela avec un toxicomane qui se shoote avec des drogues. Oh, attendez, c'est la dépendance aux injections... OK, désolé, mauvaise blague.

Answer 4

Je n'ai pas connaissance de tutoriels simplifiés, mais je peux vous donner un aperçu de ce que vous pouvez faire. 25 Une version de 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'avait pas connaissance au préalable. L'idée est de faire de l'objet plus un composant et moins une application, en relocalisant les tâches de configuration à un niveau supérieur. Cela rend l'objet plus susceptible d'être utile à l'avenir ou avec une configuration différente.

C'est mieux pour les tests, c'est mieux quand il s'agit de réviser l'application. Une implémentation typique place la configuration en XML et utilise un framework pour charger dynamiquement les classes.

Answer 5

Lorsque vous recevez une nouvelle Nintendo, vous pouvez utiliser les boutons et l'écran tactile pour jouer.

Mais à l'usine Nintendo, ils doivent savoir comment en assembler un.

Lorsque les personnes intelligentes de l'usine sortiront une Nintendo DS, elle sera différente à l'intérieur, mais vous saurez toujours comment l'utiliser.