Et ça?
Si vous avez une classe Employeeet que cet employé en a une, Address vous pouvez Employeedéfinir la classe 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;
}
}
Jusqu'à présent, tout semble bien.
Ce code montre une relation HAS-A entre l'employé et son adresse, ça va.
Maintenant, cette relation HAS-A a créé une dépendance entre eux. Le problème vient du constructeur.
Chaque fois que vous souhaitez créer une Employeeinstance, vous avez besoin d'une Addressinstance:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Travailler de cette façon devient problématique, surtout lorsque vous souhaitez effectuer des tests unitaires.
Le problème principal 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 pour ce faire. La chaîne peut devenir ingérable.
Pour éviter cela, vous pouvez changer le constructeur comme ceci:
public Employee(){
}
Utilisation d'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 glissement, si vous avez plusieurs attributs ou si les objets sont difficiles à créer.
Pourtant, pensez-y, disons, vous ajoutez l' Departmentattribut:
class Employee {
private Address address;
private Department department;
....
Si vous avez 300 employés et que tous doivent avoir le même service, et en plus ce même service doit être partagé entre d'autres objets (comme la liste des départements de l'entreprise, ou les rôles de chaque département, etc.), alors vous avoir du mal avec la visibilité de l' Departmentobjet et le partager à travers tout le réseau d'objets.
En quoi consiste l' injection de dépendances pour vous aider à "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 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 définirez quoi injecter pour un scénario donné.
Ce que le framework Dependency Injector va faire est de définir les objets appropriés pour vous, de sorte que vous n'ayez pas à coder setAddressou 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 Employeeclasse, vous pourrez injecter de la maquette Addresset des Departmentsobjets sans avoir à coder tout l'ensemble / obtenir pour tout votre test. Encore mieux, vous pouvez injecter du réel Address et des Departmentobjets dans le code de production, tout en ayant l'assurance que votre code fonctionne comme testé.
C'est à peu près tout.
Pourtant, je ne pense pas que cette explication convient à un enfant de 5 ans comme vous l'avez demandé.
J'espère que vous le trouverez toujours utile.