Estamos cerrando este ciclo de definiciones para SOLID, y en esta entrada vamos a dar un vistazo al último principio de la lista: DIP o Dependency Inversion Principle.
El Principio de Inversión de Dependencia (DIP) establece que:
- Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
- Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.
El Problema de la Dependencia Directa
Imaginate que estás construyendo una aplicación que envía notificaciones. Para empezar rápido, decidís crear un controlador que usa directamente un servicio de correo electrónico:
public class NotificationController
{
private EmailNotificationService _service = new EmailNotificationService(); // Acá tenemos dependencia directa
}Al principio, todo parece estar bien. El controlador puede enviar correos sin problema. Pero luego surge un requisito: también queremos enviar notificaciones por SMS.
Si queremos usar SmsNotificationService en lugar de EmailNotificationService, hay que modificar el controlador. Ahora supongamos que este servicio de notificación se usa en varios lugares del código. Cambiarlo en todos esos lugares
sería costoso y propenso a errores, ni hablar que tendríamos que volver a hacer las pruebas luego de los cambios.
Otro problema es que si EmailNotificationService no está terminado, el controlador ni siquiera compilaría. Esto impide que diferentes desarrolladores trabajen en paralelo en distintas partes de la aplicación. Además, de que si
queremos probar NotificationController, no podemos sustituir fácilmente EmailNotificationService por una versión simulada (un mock).
Acá es donde podemos mejorar el panorama con el Principio de Inversión de Dependencia.
Explicación del DIP
¿Qué es un módulo en este contexto?
Cuando hablamos de módulos, nos referimos a componentes de nuestra aplicación que cumplen roles específicos. Un módulo puede ser una clase, un servicio, un controlador o cualquier otra unidad de código con una función clara.
Los módulos de alto nivel, son aquellos que orquestan la lógica de negocio, como los controladores en una aplicación web.
Por otro lado los módulo de bajo nivel, son los que ejecutan funcionalidades más específicas, como los servicios que envían notificaciones o acceden a bases de datos.
Si un módulo de alto nivel depende directamente de un módulo de bajo nivel, cualquier cambio en el servicio va a afectar al controlador. DIP nos dice que en lugar de depender directamente de los módulos de bajo nivel, ambos deben
depender de una abstracción. En este contexto una abstracción suele ser una interfaz o una clase abstracta que define un "contrato" sin especificar la implementación.
Aplicando DIP en C#
Crear una Interfaz (abstracción)
En lugar de que NotificationController dependa directamente de EmailNotificationService, creamos una interfaz que defina los métodos necesarios:
public interface INotificationService
{
void SendNotification(string message);
}Ahora tanto el controlador como el servicio dependen de esta interfaz, en lugar de depender directamente uno de otro.
Implementar la Interfaz en el Servicio
public class EmailNotificationService : INotificationService
{
public void SendNotification(string message)
{
Console.WriteLine($"Enviando email: {message}");
}
}Con este cambio ahora EmailNotificationService implementa INotificationService, lo que permite cambiar la implementación en el futuro sin afectar el controlador.
Modificar el Controlador para Usar la Interfaz
En lugar de crear una instancia directa de EmailNotificationService, inyectamos una dependencia de INotificationService:
public class NotificationController
{
private readonly INotificationService _service;
public NotificationController(INotificationService service)
{
_service = service;
}
}Ahora NotificationController ya no está acoplado a EmailNotificationService, sino a una abstracción (INotificationService). Esto facilita la sustitución del servicio en el futuro.
Configurar la Inyección de Dependencias (IoC)
Para que el sistema suministre automáticamente la implementación correcta de INotificationService, debemos registrarlo en el contenedor de inyección de dependencias (IoC Inversion of Control Container):services.AddTransient<INotificationService, EmailNotificationService>();En .NET, el contenedor de IoC se configura en el Program.cs de nuestra aplicación, donde registramos las dependencias para que el framework se encargue de inyectarlas automáticamente donde sean necesarias cada vez que necesitemos usarlas.
Con esto, cada vez que se necesite un INotificationService, se creará una instancia de EmailNotificationService sin que el controlador tenga que preocuparse por ello.
El Principio de Inversión de Dependencia (DIP) nos colabora en reducir el acoplamiento entre clases, eso se traduce a mejor mantenibilidad y escalabilidad del software. Implementarlo mediante interfaces e inyección de dependencias permite que las aplicaciones sean también más fáciles de probar.
Voy a dejar un índice al final de cada hoja para facilitar la navegación entre los principios. No es que haya un orden, pero sí es cierto que están planteados en el orden de SOLID para recordarlo más fácilmente.