¿Qué hay de esto?
Si tiene una clase Employeey este empleado tiene una Address , puede Employeedefinir la clase de la siguiente manera:
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;
}
}
Todo se ve bien hasta ahora.
Este código muestra una relación HAS-A entre el empleado y su dirección, está bien.
Ahora, esta relación HAS-A creó una dependencia entre ellos. El problema viene dentro del constructor.
Cada vez que desee crear una Employeeinstancia, necesita una Addressinstancia:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Trabajar de esta manera se vuelve problemático especialmente cuando desea realizar pruebas unitarias.
El principal problema surge cuando necesita probar un objeto en particular, necesita crear una instancia de otro objeto, y lo más probable es que necesite crear una instancia de otro objeto para hacerlo. La cadena puede volverse inmanejable.
Para evitar esto, puede cambiar el constructor de esta manera:
public Employee(){
}
Usando un constructor sin args.
Luego puede configurar la dirección cuando lo desee:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Ahora, esto puede ser un arrastre, si tiene varios atributos o si los objetos son difíciles de crear.
Sin embargo, piense en esto, digamos, agrega el Departmentatributo:
class Employee {
private Address address;
private Department department;
....
Si tiene 300 empleados, y todos ellos deben tener el mismo departamento, y además ese mismo departamento debe compartirse entre otros objetos (como la lista de departamentos de la compañía, o los roles que tiene cada departamento, etc.), entonces tener dificultades con la visibilidad del Departmentobjeto y compartirlo a través de toda la red de objetos.
De qué se trata la Inyección de dependencias para ayudarlo a "inyectar" estas dependencias en su código. La mayoría de los marcos le permiten hacer esto al especificar en un archivo externo, qué objeto se va a inyectar.
Suponga un archivo de propiedades para un inyector de dependencia ficticio:
#mock employee
employee.address = MockAddress.class
employee.department = MockDepartment.class
#production setup
employee.address = RealAddress.class
employee.department = RealDepartment.class
Definirá qué inyectar para un escenario dado.
Lo que hará el marco del Inyector de dependencias es establecer los objetos correctos para usted, para que no tenga que codificar setAddresso setDepartment. Esto se haría por reflexión o por generación de código u otras técnicas.
Entonces, la próxima vez que necesite probar la Employeeclase, puede inyectar simulacros Addressy Departmentsobjetos sin tener que codificar todo el conjunto / obtener para toda su prueba. Aún mejor, puede inyectar objetos reales Address y realesDepartment en el código de producción, y aún tener la confianza de que su código funciona como se probó.
Eso es más o menos al respecto.
Aún así, no creo que esta explicación sea adecuada para un niño de 5 años como lo solicitó.
Espero que aún lo encuentres útil.