Principio de inversión de dependencias en SOLID

El principio de inversión de dependencias es la letra D de SOLID y, según muchos desarrolladores, el que más beneficios aporta al construir software mantenible. Si trabajas con código orientado a objetos y buscas reducir acoplamiento, escribir pruebas unitarias más simples y escalar tus servicios sin romperlos, este principio te interesa.

¿Qué dice el principio de inversión de dependencias?

La definición formal del dependency inversion principle establece que los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de abstracciones. Y las abstracciones, a su vez, no deben depender de los detalles: los detalles dependen de las abstracciones.

En la práctica, los módulos de alto nivel contienen la lógica de negocio y los módulos de bajo nivel manejan detalles específicos de implementación. La inversión consiste en que ambos miren hacia una interfaz común, no que uno dependa del otro directamente.

¿Qué es la inversión de dependencias en SOLID? Es un principio que obliga a que tanto las clases de alto nivel como las de bajo nivel dependan de interfaces o abstracciones, en lugar de que la lógica de negocio dependa de implementaciones concretas.

¿Cómo se ve en código un ejemplo claro?

Imagina un gestor de notificaciones. En lugar de instanciar directamente un servicio de email o de SMS, tiene un atributo de tipo INotificador, una interfaz con el método enviarMensaje. Los detalles de implementación viven en cada notificador concreto: uno por email y otro por SMS.

• Clase de alto nivel: el gestor de notificaciones, totalmente abstraído de los detalles.
• Clases de bajo nivel: el notificador por email y el notificador por SMS, que implementan la interfaz.
• Abstracción común: la interfaz INotificador, que ambos lados respetan.

Así, el gestor no sabe ni le importa cómo se envía el mensaje. Solo confía en que cualquier clase que implemente INotificador cumplirá el contrato.

¿Por qué este principio mejora la calidad del software?

Aplicar inversión de dependencias mejora la modularidad y facilita el mantenimiento, porque las clases de alto nivel como los servicios dejan de depender de implementaciones detalladas. Y aquí viene lo interesante: cambiar de implementación se vuelve trivial.

Si tienes varios algoritmos para resolver la misma tarea, intercambiarlos no debería ser un problema cuando la inversión está bien hecha. Eso reduce el acoplamiento: los cambios en módulos concretos no afectan al sistema principal. Puedes optimizar un algoritmo de bajo nivel y mejorar el tiempo de ejecución o disminuir la complejidad algorítmica sin tocar quien lo consume.

¿Cuál es el mayor beneficio de invertir dependencias?

La testabilidad. Este principio facilita el uso de mocks y stubs en pruebas, lo que te permite testear sin depender de implementaciones concretas.

Piensa en un servicio que hace consultas a una base de datos. Si dependes directamente de la base de datos, necesitas levantar todo un entorno de ejecución para probarlo. En cambio, si aplicaste inversión de dependencias, simplemente preparas un mock del servicio que hace las consultas y listo. Tus pruebas unitarias corren rápido y sin infraestructura externa.

¿Por qué la inversión de dependencias facilita las pruebas? Porque permite reemplazar dependencias reales por mocks o stubs, evitando preparar entornos complejos como bases de datos, APIs externas o servicios de terceros para correr pruebas unitarias.

Si quieres profundizar en este tema, revisa el curso de pruebas en Python disponible en Platzi.

¿Cuándo deberías aplicar la inversión de dependencias?

No todo el código necesita este nivel de abstracción. Aplícalo cuando detectes señales claras de fricción en tu base de código.

• Alto acoplamiento entre módulos de alto y bajo nivel: si tienes un servicio con varios algoritmos disponibles para resolver el mismo problema e intercambiarlos resulta engorroso, el servicio no debería depender de cómo se implementa el algoritmo, sino de una interfaz que lo defina.
• Dificultad para escribir pruebas unitarias: si crear un entorno de ejecución para probar un servicio es complicado, saca esa definición hacia otra clase y aplica el principio. Con un mock sobre la nueva dependencia, la complejidad de las pruebas baja muchísimo.
• Problemas para reutilizar componentes o escalar: cuando reutilizar lógica entre servicios se vuelve difícil, extraer esos algoritmos hacia clases independientes detrás de una abstracción te abre la puerta a usarlos en nuevas definiciones sin duplicar código.

¿Cuándo aplicar el principio de inversión de dependencias? Cuando hay alto acoplamiento, cuando las pruebas unitarias son difíciles de escribir o cuando reutilizar y escalar componentes se vuelve costoso.

La inversión de dependencias es, en muchos sentidos, la pieza que conecta el resto de los principios SOLID. Sin ella, conceptos como la sustitución de Liskov o la segregación de interfaces pierden gran parte de su poder práctico.

¿Cómo aplicarías la inversión de dependencias en el procesador de pagos que estamos construyendo? Déjame tu opinión en los comentarios y comparte qué interfaces extraerías primero.