Publicado en
Autor
Los frameworks de desarrollo se han vuelto populares por la facilidad con la cual puedes crear prototipos y aplicaciones con componentes poco acoplados. Para lograr ese bajo acoplamiento es muy común que los framework utilicen una estrategia que se conoce como inyección de dependencias.
Qué es la inyección de dependencias
La inyección de dependencias es un principio que no pertenece a un lenguaje o framework en particular, así que es común encontrar implementaciones de este principio en frameworks de distintos lenguajes. La idea detrás de la inyección de dependencias es que las clases o componentes de un sistema no deben de configurar sus dependencias de forma estática sino que deben de ser configuradas desde el exterior.
Para profundizar en el tema me valdré de un ejemplo muy sencillo pero que nos permitirá comprender el problema que resuelve la inyección de dependencias y de esa forma crear una definición.
Vamos a suponer que en nuestro sistema tenemos una clase llamada GenericClass que requiere escribir en una bitácora y para ello utiliza una clase diseñada para este propósito llamada Logger. La forma más convencional de expresar este sencillo modelo es mediante una asociación como lo muestra la figura 1.
Figura 1. Asociación
El problema con este diseño es que es poco flexible ya que si hacemos cambios en Logger tal vez también tengamos que hacer cambios en GenericClass. A este efecto se le llama alto acoplamiento.
Algunos de los problemas que puedes tener con este diseño son los siguientes.
Cambiar o actualizar Logger implica cambios en GenericClass.
La dependencia con Logger debe de estar disponible en tiempo de compilación.
GenericClass tiene la responsabilidad de crear una instancia de Logger.
No se puede probar de forma aislada GenericClass.
La forma en la que se pueden resolver estos problemas, implica que GenericClass, en lugar de depender directamente de las implementaciones de Logger, solo dependa de una abstracción que puede implementar Logger. Este cambio se muestra en la figura 2.
Figura 2. Dependencia a interface.
Ahora GenericClass solo depende de una interfaz, esto nos permite reducir el acoplamiento entre clases y darle flexibilidad a nuestro diseño. De esta forma podemos cambiar el comportamiento de Logger sin necesidad de cambiar completamente GenericClass.
En la práctica este diseño requiere que GenericClass ya no tenga el control para crear una instancia de Logger sino que se indica en la declaración de la clase, lo que obliga a que la creación de Logger esté fuera de GenericClass. Esto es lo que se conoce como inyección de dependencias ya que se requiere de otro elemento de software que proporcione una instancia de Logger que pueda utilizar GenericClass.
Con lo anterior podemos crear una definición simple y sencilla de comprender.
“La inyección de dependencias es cuando los componentes de un sistema reciben sus dependencias mediante su constructor, métodos o sus propiedades y dichos componentes no obtienen sus dependencias por ellos mismos.”
La inyección de dependencias reduce el acoplamiento entre clases, de manera que los cambios en una clase no afecten a la otra. Asimismo, las clases pueden ser probadas de forma aislada.
Tipos de inyección de dependencias
De acuerdo a la definición se puede deducir que existen tres tipos de inyección, que podemos apreciar en los listados 1, 2 y 3. En realidad, la inyección vía propiedades no es muy recomendable dado que expone detalles del cliente, pero la incluimos simplemente como ejemplo.
Listado 1. Inyección vía constructor
Listado 2. Inyección vía métodos
Listado 3. Inyección vía propiedades
La inyección de dependencias nos permite reducir el acoplamiento de los componentes de un sistema permitiendo que estos sean más reutilizables. Es aconsejable su uso en sistemas grandes pero en sistemas complejos puede ser problemático ya que las dependencias se crean en otro punto dentro de la aplicación.
Herminio Heredia (@HerminioHeredia) es Ingeniero en Sistemas Computacionales, desarrollador freelance y coordinador en laraveles.com
- Log in to post comments