Dependency Inversion Principle

La Inyección de dependencia o Dependency Inversion Principle  es uno de los principios SOLID,  no tengo idea si es uno de los principios mas usados, pero lo si tengo claro es que hay un antes y un después desde que comencé a usar la inyección de dependencias. 

¿Qué es la inyección de dependencias?, en términos prácticos. 

En términos prácticos es al almacenar en un contenedor instancias de objetos para después ser utilizada casi de forma automática, la forma de inyectar esta dependencia es mediante los parámetros del constructor. 

Casos de uso 

Siempre que se habla de ejemplos de inyección de dependencia se habla sobre la capacidad de cambiar el origen de datos ya sea cambiar de SQL server a MYSQL o cualquier otra combinación, si bien este ejemplo es valido y aplica 100%, es muy raro que se de este caso de uso, ya que muy rara vez cambias el motor de base de datos de una aplicación. 

Otro caso de uso es por ejemplo si tienes notificaciones, a lo mejor tienes notificaciones por correo electrónico, pero se requiere cambiar a notificaciones de mensajes de texto o Whatsapp. Este ya es una escenario un poco mas real. 

Por ultimo, otro caso seria si se quiere tener un log técnico en un archivo de texto o en una base de datos Como se pueden ver hay miles de ejemplos. 

 

 

Beneficios

Los beneficios de usar las inyecciones de dependencias  es principalmente cambiar las implementaciones para X  funcionalidad cambiando solo el contenedor llenado del contenedor de dependencias, pero toda nuestra aplicación seguirá funcionando.

Testing

 

Si utilizamos inyección de depencias de formas mas o menos razonable las pruebas unitarias deberían salir de forma bastante fácil creando implementación de la infraestructura en memoria, como base de datos, FTP, APIS con sistemas internos,  sistema de archivos entre muchos otros.

¿Y como funciona?

En términos prácticos funciona con interfaces y con los constructores ,  se debe poner como argumento todos  los objetos necesarios en el constructor para que la clase pueda hacer toda su funcionalidad, ojo que se debe poner interfaces, de esa forma es  la clase esta amarrada al contrato (interfaz) y no  a la implementación. 

 

En el caso de mas abajo  se puede ver  que tenemos userService y logger en el constructor,  pero en un ningún caso vemos la implementación, para definir la instancia que llegará a los constructores, se debe definir en el archivo startup.cs en el caso .NET, y pero para todos los lenguajes/framework tienen la opción de hacer inyección de dependencia. 

 

Entonces, como podemos ver  en nuestra aplicación tendríamos una implementación real para IuserAppService y de ILogger, pero en el proyecto de TEST tendríamos una implementacion "FAKE" , permitiendo testear solo nuestra lógica de negocio.

 

 --

Atte.
Victor Hugo Saavedra
http://vhspiceros.blogspot.com