Was ist damit?
Wenn Sie eine Klasse haben Employeeund dieser Mitarbeiter eine Address hat, können Sie die EmployeeKlasse wie folgt definieren lassen:
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;
}
}
Bisher sieht alles gut aus.
Dieser Code zeigt eine HAS-A- Beziehung zwischen dem Mitarbeiter und seiner Adresse, das ist in Ordnung.
Diese HAS-A- Beziehung hat nun eine Abhängigkeit zwischen ihnen geschaffen. Das Problem liegt beim Konstruktor.
Jedes Mal, wenn EmployeeSie eine AddressInstanz erstellen möchten, benötigen Sie eine Instanz:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Das Arbeiten auf diese Weise wird besonders dann problematisch, wenn Sie Unit-Tests durchführen möchten.
Das Hauptproblem kommt , wenn Sie ein bestimmtes Objekt testen müssen, müssen Sie eine Instanz von anderem Objekt erstellen, und höchstwahrscheinlich benötigen Sie eine Instanz noch zu schaffen anderen Objekt , das zu tun. Die Kette kann unhandlich werden.
Um dies zu vermeiden, können Sie den Konstruktor folgendermaßen ändern:
public Employee(){
}
Verwenden eines Konstruktors ohne Argumente.
Dann können Sie die Adresse festlegen, wann immer Sie möchten:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Dies kann ein Drag sein, wenn Sie mehrere Attribute haben oder wenn die Objekte schwer zu erstellen sind.
Denken Sie jedoch darüber nach, sagen wir, Sie fügen das DepartmentAttribut hinzu:
class Employee {
private Address address;
private Department department;
....
Wenn Sie 300 Mitarbeiter haben und alle dieselbe Abteilung haben müssen und diese Abteilung auch von einigen anderen Objekten (wie der Liste der Unternehmensabteilungen oder den Rollen der einzelnen Abteilungen usw.) gemeinsam genutzt werden muss, sind Sie hier genau richtig Es fällt Ihnen schwer, das DepartmentObjekt sichtbar zu machen und es über das gesamte Netzwerk von Objekten zu teilen.
Worum es bei der Abhängigkeitsinjektion geht, damit Sie diese Abhängigkeiten in Ihren Code " einfügen" können. In den meisten Frameworks können Sie dies tun, indem Sie in einer externen Datei angeben, welches Objekt injiziert werden soll.
Angenommen, eine Eigenschaftendatei für einen fiktiven Abhängigkeitsinjektor:
#mock employee
employee.address = MockAddress.class
employee.department = MockDepartment.class
#production setup
employee.address = RealAddress.class
employee.department = RealDepartment.class
Sie definieren, was für ein bestimmtes Szenario injiziert werden soll.
Das Dependency Injector-Framework legt die richtigen Objekte für Sie fest, sodass Sie weder codieren setAddressnoch codieren müssen setDepartment. Dies würde entweder durch Reflexion oder durch Codegenerierung oder andere Techniken erfolgen.
Wenn Sie das nächste Mal die EmployeeKlasse testen müssen, können Sie Mock Addressund DepartmentsObjekte einfügen, ohne den gesamten Satz / Abruf für alle Ihre Tests codieren zu müssen. Noch besser ist, dass Sie Real- Address und DepartmentObjekte in den Produktionscode einfügen können und trotzdem das Vertrauen haben, dass Ihr Code wie getestet funktioniert.
Das ist ziemlich viel.
Trotzdem denke ich nicht, dass diese Erklärung für einen 5-Jährigen geeignet ist, wie Sie es gewünscht haben.
Ich hoffe, Sie finden es immer noch nützlich.