Principio de Inversión de Dependencias (DIP) — es un principio arquitectónico que dice:
Esto significa que la lógica de negocio (por ejemplo, un servicio de gestión de pedidos) no debe conocer ni utilizar directamente una implementación concreta de infraestructura (por ejemplo, una clase que implemente el envío de correos), sino que debe trabajar a través de una abstracción (interface) que se inyecta a través de un contenedor DI o manualmente.
Ejemplo de código en C#:
public interface IEmailSender { void Send(string to, string message); } public class SmtpEmailSender : IEmailSender { public void Send(string to, string message) { // Implementación del envío de correo } } public class OrderService { private readonly IEmailSender _emailSender; public OrderService(IEmailSender emailSender) { _emailSender = emailSender; } public void PlaceOrder(string customer) { // lógica de negocio _emailSender.Send(customer, "¡Su pedido ha sido realizado!"); } }
Características clave:
¿Es DIP simplemente inyección de dependencias a través del constructor?
No. DIP trata sobre separar abstractions de implementaciones. La inyección de dependencias (DI) es solo una herramienta que se utiliza para implementar DIP. DIP se puede implementar incluso sin un contenedor DI, asegurando manualmente la separación entre abstracciones y detalles.
Si tienes una implementación de la interfaz, ¿es obligatorio DIP?
Sí, el principio sigue siendo aplicable si hay posibilidad de extensión. La introducción de abstracciones prepara el sistema para cambios en los requisitos sin modificar el código de alto nivel. Incluso con una sola implementación de la interfaz, el bajo acoplamiento facilita la prueba y el desarrollo del sistema.
¿Se puede violar DIP usando lógica en fábricas o localizadores de servicios?
Sí. Si una fábrica o un localizador de servicios conoce los detalles de implementación y los vincula dinámicamente sin usar una interfaz en el lado del cliente, se viola DIP, a pesar de la existencia externa de abstracciones.