He leído muchos artículos sobre Dependency Injection y he visto muchos videos, pero aún no puedo entenderlo. ¿Alguien tiene una buena analogía para explicarlo?¿Alguien tiene una buena analogía para la inyección de dependencia?
Vi la primera parte del otoño de Agile screencast y todavía estaba un poco confundido.
Analogy? Le daré un golpe ... Su reproductor de CD estéreo es inútil sin un CD con música ... (depende del CD). Si construyeron reproductores de CD con el CD ya en él, sería aburrido muy rápido ...
Así que los construyen para que pueda "inyectar" el CD, (del que depende) en el reproductor. De esta forma, puede inyectar uno diferente cada vez y obtener un comportamiento "diferente" (música) dependiendo de cuál inyecte.
El único requisito es que el CD debe ser compatible con la interfaz definido por el jugador. (No puede reproducir un disco de Blue-ray en un reproductor de CD de 1992).
¿Quizás se enfoque en la parte de "inyección"? Cuando veo ese término, pienso en jeringas. El proceso de empujar las dependencias de un componente al componente se puede considerar como una inyección en el componente.
Al igual que con el cuerpo, cuando hay algo que necesita en el camino de la medicina (un componente que necesita) puede inyectarlo en el cuerpo.
La mejor analogía que puedo pensar es la de contratar un mecánico.
Sin inyección de dependencia, contratas un mecánico y el mecánico trae sus propias herramientas. Puede tener herramientas pésimas, puede tener grandes herramientas, puede estar usando una llave de tubo cuando debería usar un enchufe. No lo sabes, y puede que no te importe, mientras él haga el trabajo.
Con inyección de dependencia, contratas a un mecánico y le proporcionas las herramientas con las que quieres que haga su trabajo. Puede elegir lo que considera que son las mejores herramientas o las más apropiadas para el trabajo que lo está contratando.
Su administrador de proyecto le pide que escriba una aplicación.
Podrías escribir un código basado en tu experiencia profesional hasta ahora, pero es poco probable que sea lo que tu PM quiere.
Mejor sería si su dependencia de PM inyectó con una especificación para la aplicación. Ahora su código va a estar relacionado con la especificación que le da.
Mejor si le dijeron dónde estaba el repositorio de origen.
Mejor si le dijeron lo que era la plataforma tecnológica.
Mejor si le dijeron cuándo tenía que hacerlo.
Etc ..
En su presentación JavaPolis 2003 (slides), Jon Tirsén & Aslak Hellesøy tenían una analogía divertida con un objeto Girl que necesita una Boy a besar. Me parece recordar que el BoyFactory a veces se conoce como un "club nocturno", pero eso no está en las diapositivas.
Con (por supuesto) no hay intención de implicar la analogía obvia (mucho mejor) que se basa en las "dependencias" del embarazo y cómo se "Inyectan" –
Otra analogía: digamos que usted es un desarrollador y cada vez que lo desee ordena directamente libros de ciencias de la computación del mercado: conoce los vendedores y sus precios. De hecho, es posible que su empresa tenga un vendedor preferido y se comunique con ellos directamente. Todo esto funciona bien, pero puede ser que un nuevo vendedor ofrezca mejores precios y su empresa quiera cambiar el vendedor preferido.
En este punto debe realizar los siguientes cambios: actualice los detalles de contacto (y otras cosas) para utilizar el nuevo vendedor. Usted todavía hace el pedido directamente.
Ahora consideramos que presentamos un nuevo paso intermedio, hay un funcionario de 'biblioteca' en la empresa y usted tiene que pasar por él para obtener los libros. Si bien hay una nueva dependencia, ahora eres inmune a cualquier cambio en el vendedor: o el vendedor cambia el modo de pago o el vendedor mismo cambia, simplemente le pides un pedido al bibliotecario y él recibe los libros por ti.
Piense en ello como una realización del patrón de "Inversión de control". Supongo que tu problema es que estás acostumbrado, no te das cuenta de que es así de simple.
Comencemos por el principio.
En los primeros días los programas seguían una ruta determinada a través del código. El orden de las funciones llamadas fue dado por el programador.
En programas interactivos, p. en su mayoría CUALQUIER programa, no se puede decir, a qué función se llama y en qué momento. Solo mira una GUI o sitio web. No puede decir a qué hora se hace clic en el botón o enlace. Entonces el "control" de lo que está pasando ya no está en el programa, está en una fuente externa. El "control" ha sido invertido. La función ya no es "actuar" sino "escuchar". Piensa en el principio de Hollywood: "No nos llames, te llamamos". Un oyente es un buen ejemplo para la realización de este patrón.
IoC se realiza mediante funciones o "métodos" en el "mundo orientado a objetos" de hoy.
"inyección de dependencias" ahora significa lo mismo, pero no para los "métodos", que hacer algo, pero para los "objetos", que Retención de datos.
Los datos ya no forman parte del objeto que los contiene. Se "inyecta" en el objeto en tiempo de ejecución. Para permanecer en Hollywood, piense en una estrella de cine, juegue al golf para hablar sobre el negocio, pero para mantenerse en forma, se humilla, minimizando su peso muscular y, por lo tanto, solo puede llevar un palo a la vez.
Por lo tanto, en el campo de golf su juego dependería en gran medida del club que esté llevando.
Por suerte para ella, hay caddies, que llevan una gran cantidad de clubes a la vez, y también tienen el conocimiento de qué club usar y en qué momento. Ahora ella es independiente de su posibilidad limitada de llevar palos de golf. "No piense en un club de concreto para usar, los conocemos todos y le damos el correcto en el momento adecuado".
La estrella de la película es el objeto y los palos de golf son los miembros del objeto. Eso es inyección de dependencia.
De Head First Design Patterns:
Recuerde, el código debe ser cerrado (a cambio) como la flor de loto en la noche, pero abierto (a la extensión) como la flor de loto en la mañana
Un objeto habilitado para DI se puede configurar inyectando comportamientos definidos en otras clases. La estructura de objeto original no tiene cambios para crear muchas variaciones. La inyección se puede hacer explícita haciendo que una clase solicite otras clases-trabajador en su constructor, o puede ser menos obvia cuando se usa el parcheo en idiomas dinámicos como Python.
Utilizando una analogía de una clase de Persona, puede tomar un marco humano básico, pasarle un conjunto de órganos y observar cómo evoluciona. La persona no sabe directamente cómo funcionan los órganos, pero sus comportamientos se confirman en una interfaz esperada e influyen en la manifestación física y mental del propietario.
¡Un mago sleight of hand! Lo que crees que ves puede ser secretamente manipulado o reemplazado.
vida está llena de analogías de inyección de dependencia:
La esencia de Inversion of Control (de la cual Dependency Injection es una implementación) es la separación entre el uso de un objeto y su administración.
La analogía/ejemplo que uso es un motor. Un motor requiere combustible para funcionar, es decir, es depdendent en el combustible. Sin embargo, el motor no puede ser responsable del combustible que necesita. Simplemente 'pregunta' por el combustible, y está provisto (típicamente por una bomba de combustible en un automóvil).
La analogía comienza a descomponerse cuando se ve demasiado profundo, en el sentido de que un motor no pide combustible, se lo da algún tipo de elemento de gestión, como una ECU. Uno podría comparar la ECU con un contenedor, pero no estoy seguro de qué tan válido sea.
Creo que una gran analogía es una niña de seis años con un juego de lego.
Quiere que sus objetos sean como los ladrillos lego. Cada uno es independiente de todos los demás y, sin embargo, ofrece una interfaz clara para conectarlos a los demás. Al conectarlos juntos, realmente no importa exactamente qué dos ladrillos unir siempre que tengan una interfaz correspondiente.
Su marco de inyección de dependencia es como el de seis años de edad. Sigue las instrucciones (es decir, su archivo de configuración, anotaciones, etc.) para conectar ladrillos específicos de determinadas maneras para crear un modelo en particular.
Por supuesto, dado que las interfaces de los ladrillos son bastante generalizadas, pueden combinarse de muchas maneras diferentes, por lo que es fácil crear nuevos conjuntos de instrucciones que el niño de seis años pueda usar modelo diferente de los mismos ladrillos.
Agradable. Para ampliarlo, el jugador conoce los CD en general, cómo leerlos, etc. (la interfaz), pero no sabe nada sobre un álbum específico (implementación). – ctacke
¡Gran analogía! Tendré que recordar este. – chills42
Excelente. Va en mi caja de herramientas. – Will