El patrón inyección de dependencias

Descripción general:

El patrón inyección de dependencias, es una técnica que como su nombre lo indica busca facilitar la resolución de dependencias entre objetos.

Introducción conceptual

Podríamos decir sin temor a equivocarnos, que el auge del patrón de injección de dependencias, se produjo a partir de un libro escrito por Rod Johnson en el año 2004, titulado “J2EE Development without EJB”. Si bien la idea de inversión de control que dió origen al patrón de inyección de dependencias venía debatiéndose en la comunidad con anterioridad, fue el mencionado libro, el que de alguna forma popularizó el patrón marcando el hito fundacional. En este libro Johnson propone la utilización de contenedores livianos en conjunto con técnicas de programación orientada a aspectos para reemplazar el

uso de contenedores EJB.

Figura 1: Planteo inicial del problema
Figura 1: Planteo inicial del problema

El patrón inyección de dependencias,

es una técnica que como su nombre lo indica busca facilitar la resolución de dependencias entre objetos.

Veamos un ejemplo ilustrativo para entender que es lo que se propone. Tal como muestra el diagrama de la figura 1, supongamos que tenemos una clase que tiene como responsabilidad realizar búsquedas de películas. Para poder cumplir con su cometido, cada instancia de esta clase, requiere de un objeto que implemente la interface ICatalogoPeliculas . Es aquí donde debemos comenzar a tomar decisiones, ¿Quién es el encargado de resolver esta dependencia? Una primera alternativa seria que la propia clase BuscadorPeliculas , se encargara de instanciar al catálogo, pero esto agregaría una responsabilidad extra a la clase BuscadorPeliculas incrementando al mismo tiempo el acoplamiento. Otra alternativa podría ser que sea la clase VideoClub la encargada de instanciar tanto al buscador como al catálogo y luego resolver la dependencia, el problema aquí es similar al caso anterior, pero aquí la responsabilidad adicional la estaría tomando clase VideoClub.

El patrón en cuestión propone introducir una nueva clase (Inyector1), que funcionando en forma similar a un Factory [factory], se encargue de resolver las dependencias, permitiéndonos adicionalmente separar la interface de implementación.

Si quisiéramos dar un paso más en nuestro ejemplo, podríamos plantear la existencia de varios tipos de buscadores e independizar al VideoClub del buscador específico a utilizar mediante la utilización del Inyector. Esto nos daría como resultado la situación ilustrada en la figura 2.

Figura 2: Solución con IoC
Figura 2: Solución con IoC