Dependency Injection
Este es un patrón de diseño que había escuchado varias veces, pero como en varios libros que había leído y más concretamente en Head First Design Patterns no salía pues lo había dejado un poco de lado.
Creo que el nombre fue lo que me echaba un poco para atrás para profundizar sobre él. Pero la complejidad del concepto es inversamente proporcional al mote que le han puesto. De hecho cuando lo comprendes te choca que sea realmente un patrón de diseño. Vamos a ver a que se refiere DI y las razones por las que nos puede beneficiar.
Normalmente en el desarrollo hacemos objetos que tiene dependencias de otros objetos. Un ejemplo básico y fácil de comprender. Un objeto coche necesita un objeto motor.
El problema que sugiere arreglar el patrón de DI es que el motor no se construya en el mismo proceso que se construye el coche sino que el motor en sí se prepare en otro momento(antes de empezar a montar el coche o al menos tenerlo preparado para cuando sea necesario).
¿Cómo se traspasa esta idea al código?
Como se puede apreciar es un patrón que seguramente hayamos usado en muchos casos en nuestro propio código sin saber asociarlo a este nombre.
¿En qué puede ayudarnos?
Normalmente las lecturas indican que esta forma de trabajar ayudan al testeo del código, ya que cuando los objetos se crean y trabajan de forma interna (no decir ya cuando está totalmente oculto su funcionamiento y por lo tanto un acceso muy complicado) son difíciles de mockear y esto lleva a invertir mucho tiempo a la escritura de tests.
A través de DI es muy fácil hacer un Dummy Object que extienda/implemente la clase/interface y que haga exactamente lo que queramos testear en cada momento.
El Extra - Inyector de Dependencias
A lo largo de mis lecturas y con mi objetivo un poco difuso he vislumbrado un segundo objetivo mucho más potente pues está enfocado a la limpieza del código junto a la automatización de tareas y puede que incluso asociado a la eficiencia.
El concepto que nos da el extra es el Inyector de Dependencias.
La idea es que haya un objeto que conozca las interrelaciones de dependencias entre los objetos y cuando un objeto necesite una dependencia sepa donde pueda preguntar y sea atendido.
Esta idea conducida por una serie de convenciones en el código que te ayuden a automatizar el proceso de configuración de ese objeto Inyector. En grandes aplicaciones la complejidad de esta configuración me imagino que puede llegar a ser muy vasta, ¿por qué no tener un configurador automático que haga esta tarea sin errores?
Contexto Android
Si nos situamos en el mundo Android se puede observar rápidamente el beneficio de DI e Inyector de Dependencias.
En Android tenemos una clase que es obligada para realizar cualquier cosa fuera de la lógica propia de nuestra aplicación: UI, Cámara, Location, etc. y es la Clase Contexto. No he visto el código fuente de todas estas cosas pero por el sistema de seguridad deduzco que para realizar cualquier acción Android necesita saber desde el Contexto que intenta tomar los recursos concretos para ver si tiene permisos sobre ellos. A continuación un pequeño enlace para descubrir este maravilloso mundo.
+23.33.33.png)
Por esta razón la inyección de Contextos para nuestras clases va a ser bastante frecuente. La labor del desarrollador sería marcar de alguna manera concreta aquellas clases que necesiten un Contexto concreto y olvidarse. Será tarea del inyector darle un Contexto en el caso concreto.
Material Recolectado para la entrada
Material Recolectado para la entrada
(Cosita Güena) Jakob Jenkov - What is Dependency Injection?
StackOverflow - How to explain dependency injection to a 5-year old?
No comments:
Post a Comment