Pregunta

He leído muchos artículos sobre la inyección de dependencias y he visto muchos videos, pero todavía no puedo entenderlo. ¿Alguien tiene una buena analogía para explicarlo?

Vi la primera parte del otoño de Screencast Agile y todavía estaba un poco confundido.

¿Fue útil?

Solución

Analogía ? Le daré un toque ... Tu 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 incluido, se aburriría muy rápido ...

Así que los construyen para que puedas " inyectar " el CD, (del cual depende) en el reproductor. De esa manera, puede inyectar una diferente cada vez, y obtener " diferente " Comportamiento (música) dependiente de cuál inyectar.

El único requisito es que el CD debe ser compatible con la interfase definida por el jugador. (No puede reproducir un disco de rayos azules en un reproductor de CD de 1992).

Otros consejos

La mejor analogía que se me ocurre es la de contratar a un mecánico.

Sin la inyección de dependencia, usted contrata a un mecánico y el mecánico trae sus propias herramientas. Él puede tener herramientas malas, puede tener herramientas excelentes, puede estar usando una llave de tubo cuando debería usar una toma de corriente. No sabe, y puede que no le importe, siempre y cuando él haga el trabajo.

Con la inyección de dependencia, contrata a un mecánico y le proporciona las herramientas con las que desea que haga su trabajo. Puedes elegir lo que consideras que son las mejores herramientas o las más adecuadas para el trabajo que le estás contratando.

Piense en ello como una realización de la " Inversión de control " modelo. Supongo que tu problema es que estás tan acostumbrado que no te das cuenta de que es tan simple.

Empecemos 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, por ejemplo, En su mayoría CUALQUIER programa, no se puede decir, qué función se llama a qué hora. Basta con mirar una GUI o sitio web. No se puede decir, a qué hora se hace clic en el botón o enlace. Así que el " control " Lo que está sucediendo ya no está en el programa, está en una fuente externa. El " control " Se ha invertido. La función ya no está " actuando " es en cambio " escucha " ;. Piense en el principio de Hollywood: "No nos llame, le 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 dependencia " ahora significa lo mismo, pero no para " métodos " ;, que hace algo , pero para " objetos " ;, que retiene datos .

Los datos ya no forman parte del objeto que lo contiene. Es " inyectado " en el objeto en tiempo de ejecución. Para permanecer en Hollywood, piense en una estrella de cine, jugar al golf para hablar del negocio, pero para mantenerse en forma, se agota, minimiza 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 lleva.

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 a qué hora. Ahora ella es independiente de su limitada posibilidad de llevar palos de golf. "No pienses en un club de concreto para vestir, los conocemos a todos y te damos el correcto en el momento adecuado".

La estrella de cine es el objeto y los clubes de golf son los miembros del objeto. Eso es inyección de dependencia.

Tal vez se centre en la " inyección " ¿parte? Cuando veo ese término, pienso en jeringas. El proceso de empujar las dependencias de un componente al componente puede considerarse como una inyección en el componente.

Al igual que con el cuerpo, cuando hay algo que necesita en la forma de la medicina (un componente que necesita), puede inyectarlo en el cuerpo.

En su presentación de JavaPolis de 2003 ( diapositivas ), Jon Tirsén & amp; Aslak Hellesøy tenía una analogía divertida con un objeto Girl que necesita un Boy para besar. Me parece recordar que el BoyFactory a veces se conoce como un 'club nocturno', pero eso no está en las diapositivas.

Otra analogía: déjenos decir que usted es un desarrollador y siempre que quiera, solicite directamente libros de informática al mercado: conoce a los vendedores y sus precios. De hecho, su empresa puede tener un vendedor preferido y usted se comunica directamente con ellos. Todo esto funciona bien, pero es posible que un nuevo vendedor ofrezca mejores precios y su empresa desea cambiar al vendedor "preferido".

En este punto, debe realizar los siguientes cambios: actualizar los detalles de contacto (y otras cosas) para usar al nuevo vendedor. Todavía haces el pedido directamente.

Ahora, consideremos que introducimos un nuevo paso en el medio, 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 es inmune a cualquier cambio en el vendedor: ya sea que el vendedor cambie la forma de pago o el vendedor mismo se cambie, simplemente le hace un pedido al bibliotecario y él recibe los libros para usted.

Desde Head First Design Patterns :

  

Recuerde, el código debe estar cerrado (para cambiar) como la flor de loto en la noche, pero abierto (en extensión) como la flor de loto en la mañana

Un objeto habilitado para DI puede configurarse inyectando comportamientos definidos en otras clases. La estructura del objeto original no tiene cambios para crear muchas variaciones. La inyección se puede hacer explícita haciendo que una clase solicite otras clases de trabajadores en su constructor, o puede ser menos obvio cuando se utiliza la creación de parejas en lenguajes 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 confirman una interfaz esperada e influyen en la manifestación física y mental del propietario.

juego de manos de un mago ! Lo que creas que veas puede ser manipulado o reemplazado en secreto.

La vida está llena de analogías de inyección de dependencia:

  • impresora - cartucho
  • dispositivo digital - batería
  • letra - sello
  • músico - instrumento
  • autobús - conductor
  • enfermedad - píldora

La esencia de la Inversión de control (de la cual Dependency Injection es una implementación) es la separación del uso de un objeto de la administración del mismo.

La analogía / ejemplo que uso es un motor. Un motor requiere combustible para funcionar, es decir, es dependiente del combustible. Sin embargo, el motor no puede ser responsable del combustible que necesita. Simplemente "pide" combustible y se proporciona (generalmente, mediante una bomba de combustible en un automóvil).

La analogía comienza a descomponerse cuando se mira demasiado profundo, en el sentido de que un motor no solicita combustible, se le proporciona mediante algún tipo de elemento de administración, como una ECU. Uno podría ser capaz de comparar la ECU con un contenedor, pero no estoy seguro de cuán válido es esto.

Tu administrador de proyectos te pide que escribas 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 le inyectara a usted una especificación para la aplicación. Ahora su código estará relacionado con la especificación que le proporcione.

Mejor si le dijeron dónde estaba el repositorio de origen.

Mejor si le dijeron qué era la plataforma tecnológica.

Mejor si le dijeron cuándo tenía que hacerlo.

Etc ..

Creo que una gran analogía es una niña de seis años con un juego de legos.

Quieres que tus objetos sean como los ladrillos de lego. Cada uno es independiente de todos los demás y, sin embargo, ofrece una interfaz clara para conectarlos a los demás. Cuando se conectan entre sí, realmente no importa exactamente cuáles son los dos bloques que se enganchan, siempre y cuando tengan una interfaz que coincida.

Su marco de inyección de dependencia es como el de seis años. Sigue las instrucciones (es decir, su archivo de configuración, anotaciones, etc.) para conectar ladrillos específicos entre sí de ciertas formas para hacer un modelo en particular.

Por supuesto, dado que las interfaces de los ladrillos son bastante generalizadas, pueden ir juntas de muchas maneras diferentes, por lo que es fácil idear nuevos conjuntos de instrucciones que el niño de seis años puede usar para hacer una modelo de los mismos ladrillos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top