dependency injection - inyeccion - ¿Alguien tiene una buena analogía para la inyección de dependencia?
inyeccion de dependencias php (12)
He leído muchos artículos sobre Dependency Injection y he visto muchos videos, pero todavía no puedo entenderlo. ¿Alguien tiene una buena analogía para explicarlo?
Vi la primera parte del screencast de Autumn of Agile y todavía estaba un poco confundido.
¡La prestidigitación de un mago! Lo que crees que ves puede ser secretamente manipulado o reemplazado.
¿Tal vez 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.
De los patrones de diseño de Head First :
Recuerde, el código debe estar cerrado (para cambiar) como la flor de loto en la noche, pero abierto (a 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.
Usando una analogía de una clase de Persona, puedes tomar un marco humano básico, pasarle un conjunto de órganos y ver 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.
La mejor analogía que puedo pensar es la de contratar un mecánico.
Sin inyección de dependencia, contratas a 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 la 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.
La vida está llena de analogías de inyección de dependencia:
- cartucho de impresora
- dispositivo digital - batería
- carta - sello
- músico - instrumento
- conductor de autobús
- enfermedad - píldora
Otra analogía: digamos que usted es un desarrollador y siempre 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: actualizar los detalles de contacto (y otras cosas) para usar el nuevo vendedor. Usted todavía hace el pedido directamente.
Ahora consideremos que presentamos un nuevo paso intermedio, hay un oficial 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.
Piénselo 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.
Empecemos desde el principio.
En los primeros días, los programas seguían un camino determinado a través del código. El orden de las funciones llamadas fue dado por el programador.
En los programas interactivos, por ejemplo, principalmente 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.
La "Inyección de Dependencia" ahora significa lo mismo, pero no para los "métodos", que hacen algo , sino para los "objetos", que contienen datos .
Los datos ya no son 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.
Entonces, 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 un montón de clubes al mismo tiempo, 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 correcto".
La estrella de cine es el objeto y los palos de golf son los miembros del objeto. Eso es inyección de dependencia.
Su gerente 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.
Sería mejor si su dependencia de PM lo inyectara 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 te dijeran dónde estaba el repositorio de origen.
Mejor si te dijeran qué era la plataforma tecnológica.
Mejor si te dijeran cuándo tenía que hacer esto.
Etc ..
En su presentación 2003 de JavaPolis ( diapositivas ), Jon Tirsén y Aslak Hellesøy tuvieron una analogía divertida con un objeto de Girl que necesita un Boy para besarse. Me parece recordar que BoyFactory veces se conoce como "discoteca", pero eso no está en las diapositivas.
La esencia de Inversion of Control (del cual Dependency Injection es una implementación) es la separación del uso de un objeto del manejo del mismo.
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, sino que 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 un niño de seis años con un juego de lego.
Quieres que tus 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. Él sigue las instrucciones (es decir, su archivo de configuración, anotaciones, etc.) para conectar ladrillos específicos juntos de ciertas maneras para hacer 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 idear nuevos conjuntos de instrucciones que el niño de seis años pueda usar para crear un modelo completamente diferente. los mismos ladrillos.
Analogía ? Le daré un golpe ... Su reproductor de CD estéreo es inútil sin un CD con música ... (depende del CD). Si construyeran reproductores de CD con el CD ya en él, sería aburrido muy rápido ...
Entonces los construyen para que pueda "inyectar" el CD, (del cual depende) al 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 definida por el jugador. (No puede reproducir un disco de rayos azules en un reproductor de CD 1992).