¿Cómo explicar la inyección de dependencia a un niño de 5 años? [cerrado]

¿Cuál es una buena manera de explicar la inyección de dependencia ?

Encontré varios tutoriales en Google, pero ninguno de ellos supondría que el lector es solo un principiante de Java. ¿Cómo le explicaría esto a un novato?

Te doy una inyección de dependencia para niños de cinco años.

Cuando vayas y saques cosas del refrigerador por ti mismo, puedes causar problemas. Puede dejar la puerta abierta, puede obtener algo que mamá o papá no quieren que tenga. Incluso podría estar buscando algo que ni siquiera tenemos o que ha expirado.

Lo que debe hacer es declarar una necesidad, "Necesito algo de beber con el almuerzo", y luego nos aseguraremos de que tenga algo cuando se siente a comer.

¿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.

Al escribir una clase, es natural que haga uso de otros objetos. Puede tener una conexión de base de datos, por ejemplo, o algún otro servicio que utilice. Estos otros objetos (o servicios) son dependencias. La forma más sencilla de escribir el código es simplemente crear y usar esos otros objetos. Pero esto significa que su objeto tiene una relación inflexible con esas dependencias: no importa por qué está invocando su objeto, utiliza las mismas dependencias.

Una técnica más poderosa es poder crear su objeto y proporcionarle dependencias para usar. Por lo tanto, puede crear una conexión de base de datos para usar y luego entregarla a su objeto. De esta manera, puede crear su objeto con diferentes dependencias en diferentes momentos, haciendo que su objeto sea más flexible. Esta es la inyección de dependencias, donde "inyecta" las dependencias en el objeto.

Por cierto: en el estilo de presentación moderno de usar fotos de flickr para ilustrar conceptos, esto podría ilustrarse con un adicto que se inyecta drogas. Oh, espera, eso es dependencia de la inyección ... OK, lo siento, broma mala.

No conozco ningún tutorial simplificado, pero puedo darle una versión de casi 25 250 palabras o menos:

Con la inyección de dependencia, un objeto no configura sus propios componentes en función de cosas que ya sabe, sino que el objeto está configurado por una lógica de nivel superior, y luego llama a componentes que no tenía conocimiento previo incorporado. La idea es hacer que el objeto sea más un componente y menos una aplicación, reubicando las tareas de configuración en un nivel superior. Esto hace que sea más probable que el objeto sea útil en el futuro o con una configuración diferente.

Es mejor para las pruebas, es mejor cuando llega el momento de revisar la aplicación. Una implementación típica coloca la configuración en XML y utiliza un marco para cargar clases dinámicamente.

Cuando te dan una nueva Nintendo, puedes usar los botones y la pantalla táctil para jugar.

Pero en la fábrica de Nintendo, necesitan saber cómo armar uno.

Cuando las personas inteligentes en la fábrica traigan una Nintendo DS, será diferente por dentro, pero aún así sabrán cómo usarla.