Quelle est une bonne façon d’expliquer injection de dépendance ?
J'ai trouvé plusieurs tutoriels sur Google, mais aucun d'entre eux qui suppose que le lecteur n'est qu'un débutant Java. Comment expliqueriez-vous cela à un novice?
Je vous donne l'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. Vous pouvez laisser la porte ouverte, vous pourriez avoir quelque chose que maman ou papa ne veut pas que vous ayez. Vous pourriez même être à la recherche de quelque chose que nous n'avons même pas ou qui a expiré.
Ce que vous devriez faire, c'est énoncer un besoin: "J'ai besoin de boire quelque chose avec le déjeuner", puis nous veillerons à ce que vous ayez quelque chose lorsque vous vous asseyez pour manger.
Et ça?
Si vous avez une classe Employee
et que cet employé a un Address
, vous pouvez définir la classe Employee
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 va bien jusqu'à présent.
Ce code montre une relation HAS-A entre l'employé et son adresse, c'est bien.
Maintenant, cette relation HAS-A a 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 en particulier lorsque vous souhaitez 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'objet other pour le faire. La chaîne peut devenir ingérable.
Pour éviter cela, vous pouvez changer le constructeur de la manière suivante:
public Employee(){
}
Utiliser un constructeur sans argument.
Ensuite, vous pouvez définir l'adresse quand vous le souhaitez:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Maintenant, cela peut être un problème, si vous avez plusieurs attributs ou si les objets sont difficiles à créer.
Pourtant, pensez à cela, ajoutons l’attribut Department
:
class Employee {
private Address address;
private Department department;
....
Si vous avez 300 employés et que tous doivent avoir le même département, et que ce même département doit être partagé entre d'autres objets (comme la liste des départements de l'entreprise ou les rôles de chaque département). avoir etc) alors vous aurez du mal avec la visibilité de l'objet Department
et de le partager à travers tout le réseau d'objets.
Qu'est-ce que l'injection de dépendance a pour but de vous aider à bien, "inject") ==) 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 de dépendance 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 quoi injecter pour un scénario donné.
Le framework Dependency Injector va définir les objets corrects pour vous, de sorte que vous n’ayez pas à coder setAddress
ou setDepartment
. Cela se ferait 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 la classe Employee
, vous pourrez injecter des objets fictifs Address
et Departments
sans avoir à coder tous les ensembles/obtenir pour tous vos tests. Mieux encore, vous pouvez injecter des objets réelsAddress
et Department
dans le code de production, tout en gardant l'assurance que votre code fonctionne correctement.
C'est à peu près à ce sujet.
Néanmoins, je ne pense pas que cette explication convient à un enfant de 5 ans, comme vous l'avez demandé.
J'espère que vous le trouvez toujours utile.
Lors de l'écriture d'une classe, il est naturel qu'elle utilise d'autres objets. Vous pouvez avoir une connexion de base de données, par exemple, ou un autre service que vous utilisez. Ces autres objets (ou services) sont des dépendances. Le moyen le 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 la raison pour laquelle vous appelez 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. Vous pouvez donc créer une connexion de base de données à utiliser, puis la remettre à votre objet. De cette façon, vous pouvez créer votre objet avec différentes dépendances à différents moments, ce qui le rend plus flexible. C'est l'injection de dépendance, où vous "injectez" les dépendances dans l'objet.
BTW: Dans le style de présentation moderne consistant à utiliser des photos sur flickr pour illustrer des concepts, cela pourrait être illustré par un toxicomane se droguant avec de la drogue. Oh, attends, c'est de la dépendance à l'injection ... OK, désolée, mauvaise blague.
Je ne connais aucun tutoriel simplifié, mais je peux vous en donner un aperçu. 25 Version de 250 mots ou moins:
Avec l'injection de dépendances, un objet ne configure pas ses propres composants en fonction de choses déjà connues, mais est configuré par une logique de niveau supérieur, puis appelle des composants dont il ne dispose pas de connaissance préalable. L'idée est de faire de l'objet davantage un composant et moins une application, en déplaçant les tâches de configuration à un niveau supérieur. Cela rend l'objet plus susceptible d'être utile dans le futur ou avec une configuration différente.
C'est mieux pour les tests, c'est mieux quand vient le temps de réviser l'application. Une implémentation typique met la configuration en XML et utilise un framework pour charger dynamiquement les classes.
Lorsque vous recevez un nouveau Nintendo, vous pouvez simplement utiliser les boutons et l'écran tactile pour jouer à des jeux.
Mais à l'usine Nintendo, ils ont besoin de savoir comment en assembler un.
Lorsque les gens intelligents de l'usine sortiront une Nintendo DS, l'intérieur sera différent, mais vous saurez toujours comment vous en servir.