Inyección de Dependencias

En los comienzos de la programación, los programas eran lineales. El flujo de ejecución era simple y predecible, ejecutándose línea tras línea.
Aparecieron dos conceptos para estructurar el código: la modularidad y la reutilización de los componentes: se crean bibliotecas de componentes reutilizables. El flujo se complica, saltando de componente a componente, y aparece un nuevo problema: la dependencia (acoplamiento) entre las clases.
El problema de la dependencia se empieza a considerar lo suficientemente importante como para definir nuevos conceptos en el diseño.

Inyección de Dependencias (en inglés Dependency Injection, DI).

Originalmete, Inyección de Dependencias era referido por el nombre de Inversión de Control pero en un articulo escrito a inicios del 2004, Martin Fowler pregunto que aspectos de control son invertidos. Martin Fowler concluyo que la adquisición de dependecias era lo que se invertía. Basado en este hecho el definió que la frase "Inyección de Dependencias" sería un mejor termino utilizado de aquí en adelante.

Cualquier aplicación no trivial esta compuesta de dos o mas clases que colaboran para lograr un objetivo de la lógica del negocio. Tradicionalmente cada objeto es responsable de obtener sus propias referencias de los objetos que colaboran con él. Esto puedo llevarnos a acoplamientos rígidos y código difícil de probar.

Cuando aplicamos Inyección de Dependencias a los objetos le son proporcionadas sus dependencias en el tiempo de su creación por una entidad externa que coordina cada objeto en el sistema. En otras palabras, las dependencias son inyectadas en los objetos. En este sentido la Inyección de Dependencias significa una inversión de responsabilidad con respecto de como el objeto obtiene las referencias  de los objetos con los que colabora.

El principal beneficio de la Inyección de Dependencias es el bajo acoplamiento. Si un objeto solo conoce sus dependencias por una interface (no sus implementaciones o como están instanciadas) entonces las dependencias pueden intercambiarse con una implementación diferente sin que los objetos dependientes conozca sus diferencias.

Por ejemplo sin una clase Banco solo conoce a su clase dependiente Cliente a través de su interface entonces la implementación actual de Cliente no tiene importancia para la clase Banco. Cliente podría ser un Pojo, un Webservice, un Ejb, o un objeto Mock para una prueba unitaria. como comentamos la clase Banco no le interesa saber de que tipo es la implementación de la clase Cliente.


En cierto modo es una implementación del Principio de Hollywood, una metodología de diseño de software, cuyo nombre proviene de las típicas respuestas que se les dan a los actores amateurs en las audiciones que tienen lugar en la meca del cine: no nos llames; nosotros te llamaremos.