Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Unidad 01
Unidad 01
UNIDAD 01
PATRON INYECCION DE DEPENDENCIAS
CONTENIDO
INTRODUCCIÓN ............................................................................................................................................. 3
EL PROBLEMA ............................................................................................................................................... 4
SOLUCIÓN ....................................................................................................................................................... 5
USOS ................................................................................................................................................................ 6
APLICABILIDAD ........................................................................................................................................... 11
CONCLUSIÓN ............................................................................................................................................... 12
La principal ventaja de usar el patrón DI es la reducción del acoplamiento entre una clase y
las clases de las cuales depende.
Figura 1
Figura 2
Con respecto a la Figura 2, el control de cómo un objeto A (De tipo ClassA) obtiene la
referencia de un objeto B (De tipo ServiceB) es invertido. El objeto A no es responsable de
obtener una referencia al objeto B, sino que es el componente externo (Builber) el
responsable de esto. Esta es la base del patrón DI.
▪ Se desee desacoplar las clases de sus dependencias de tal manera que las mismas
puedan ser reemplazadas o actualizadas con muy pocos o casi ningún cambio en el
código fuente de sus clases. Un caso ilustrativo es cuando en la empresa deciden
cambiar de motor de base de datos, o quizás en la sucursales se utilizará un motor
de base de datos diferente de menor costo de licenciamiento.
▪ Desea escribir clases que dependan de otras clases cuyas implementaciones no son
conocidas en tiempo de compilación.
▪ Desea testear las clases aisladamente sin sus dependencias.
▪ Desea desacoplar las clases de ser responsables de localizar y gestionar el tiempo
de vida de sus dependencias.
Considerando un diseño de dos capas donde tenemos una capa service donde se
implementa los componentes de negocio, y una capa DAO donde se implementa los
componentes de persistencia, se tiene una clase VentaService y una interface
VentaDaoApi, VentaService depende de VentaDaoApi para operar correctamente. El
diagrama lo tenemos en la Figura 3
Figura 3
interface VentaDaoApi{
// Some code
}
// Some code
}
// Some code
}
La clase VentaService tiene implementado el método set para hacer la inyección del objeto
respectivo:
// Some code
}
Otra desventaja es que al utilizar setters (necesarios para la inyección), estamos exponiendo
las propiedades de un objeto al mundo exterior cuando en realidad no era un requerimiento
de negocio hacerlo.
// Some code
}
En el siguiente ejemplo, seguimos con el caso de la Figura 3, a toda clase que implemente
VentaServiceApi se le podrá inyectar cualquier objeto que implemente VentaDaoApi
mediante el método injectVentaDao.
interface VentaServiceApi{
void injectVentaDao(VentaDaoApi ventaDao);
}
// Some code
}
APLICABILIDAD
Cuando utilizar DI
La inyección de dependencias no debería usarse siempre que una clase dependa de otra,
sino más bien es efectiva en situaciones específicas como las siguientes:
Contenedores
Para implementar el patrón DI en alguna de sus variantes, existen los denominados
contenedores de inyección de dependencias (DIC), que son los componentes encargados
de instanciar las dependencias y realizar las inyecciones necesarias entre todos los objetos
y además gestionar sus respectivos ciclos de vida.
El hecho de que el contenedor a veces mantenga una referencia a los componentes creados
luego de la instanciación es lo que lo hace un contenedor.
No todos los objetos deben ser gestionados. El contenedor mantiene una referencia a
aquellos objetos que son reusados para futuras inyecciones, como singletons. Cuando
configuramos el contenedor para que siempre cree nuevas instancias, entonces éste se
suele olvidar de dichos objetos creados, dejando la tarea al garbage collection para
recolectarlos luego de que dejen de ser usados.
Existen varios DIC, según el lenguaje de programación que soportan, que modos de DI que
soportan, etc. Para Java el más conocido es Spring Frameworks, pero existen otros como
Butterfly Container, Pico Container, Google Guice, y otros.
CONCLUSIÓN
La natural mutabilidad de las partes o módulos de un sistema, hace que el desarrollar
software con mínimo acoplamiento entre sus componentes sea una necesidad mas que un
mero requerimiento.
En estos contextos, la aplicación del patrón DI es una de las primeras decisiones que deben
tomarse en el diseño de la arquitectura de un producto software.
http://gcoronelc.github.io
Tener bases sólidas de programación muchas veces no es fácil, creo que es principalmente
por que en algún momento de tu aprendizaje mezclas la entrada de datos con el proceso de
los mismos, o mezclas el proceso con la salida o reporte, esto te lleva a utilizar malas
prácticas de programación que luego te serán muy difíciles de superar.
En este curso aprenderás las mejores prácticas de programación para que te inicies con
éxito en este competitivo mundo del desarrollo de software.
Cada tema está desarrollado con ejemplos que demuestran los conceptos teóricos y
finalizan con un proyecto aplicativo.
En este curso aprenderás a programas bases de datos Oracle con JDBC utilizando los
objetos Statement, PreparedStatement, CallableStatement y a programar transacciones
correctamente teniendo en cuenta su rendimiento y concurrencia.
En este curso aprenderás a programas las bases de datos ORACLE con PL/SQL, de esta
manera estarás aprovechando las ventas que brinda este motor de base de datos y
mejoraras el rendimiento de tus consultas, transacciones y la concurrencia.