Principio de inversión de dependencias en SOLID

Curso de Patrones de Diseño y SOLID en Python

Contenido del curso

Patrones de Diseño y Principios SOLID

1
Patrones de diseño y SOLID en Python
02:07 min

Principios SOLID

Reestructuración del proyecto

13
Reestructuración con módulos de Python y SOLID
13:32 min

Patrones de Diseño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:004:13

Principio de inversión de dependencias en SOLID

Curso de Patrones de Diseño y SOLID en Python

Clase 11 de 27

Clase 11 / 27

Recursos

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.

Resumen

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

¿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?

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?

¿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.

¿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.

¿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.

class EmailNotifier:

&#x20;   def send\_email(self, message):

&#x20;       print(f"Sending email with message: {message}")

class OrderProcessor:

&#x20;   def \_\_init\_\_(self):

&#x20;       self.notifier = EmailNotifier()

&#x20;   def process\_order(self, order):

&#x20;       \# Procesar el pedido (lógica ficticia)

&#x20;       print(f"Processing order: {order}")

&#x20;       self.notifier.send\_email("Order processed successfully.")

from abc import ABC, abstractmethod

\# Interfaz Notifier

class Notifier(ABC):

&#x20;   @abstractmethod

&#x20;   def send(self, message):

&#x20;       pass

\# Implementación concreta para enviar notificaciones por email

class EmailNotifier(Notifier):

&#x20;   def send(self, message):

&#x20;       print(f"Sending email with message: {message}")

\# Implementación concreta para enviar notificaciones por SMS

class SMSNotifier(Notifier):

&#x20;   def send(self, message):

&#x20;       print(f"Sending SMS with message: {message}")

\# OrderProcessor depende de la abstracción Notifier

class OrderProcessor:

&#x20;   def \_\_init\_\_(self, notifier: Notifier):

&#x20;       self.notifier = notifier

&#x20;   def process\_order(self, order):

&#x20;       \# Procesar el pedido (lógica ficticia)

&#x20;       print(f"Processing order: {order}")

&#x20;       self.notifier.send("Order processed successfully.")

\# Usando EmailNotifier

email\_notifier = EmailNotifier()

processor\_with\_email = OrderProcessor(email\_notifier)

processor\_with\_email.process\_order("Order #1")

\# Output:

\# Processing order: Order #1

\# Sending email with message: Order processed successfully.

\# Usando SMSNotifier

sms\_notifier = SMSNotifier()

processor\_with\_sms = OrderProcessor(sms\_notifier)

processor\_with\_sms.process\_order("Order #2")

\# Output:

\# Processing order: Order #2

\# Sending SMS with message: Order processed successfully.

Wilbertson Mojica Cifuentes

Hace 2 años

Dejo un ejemplo de codigo que incumple con el DIP

class Superman:
    def save_the_day(self):
        return "Superman is saving the day!"

class Batman:
    def save_the_day(self):
        return "Batman is saving the day!"

class HeroManager:
    def __init__(self):
        self.superman = Superman()
        self.batman = Batman()

    def action(self):
        print(self.superman.save_the_day())
        print(self.batman.save_the_day())

Wilbertson Mojica Cifuentes

Hace 2 años

Módulos de Alto Nivel: Son aquellos que contienen la lógica de negocio principal del sistema. Estos módulos son los responsables de ejecutar el flujo general de la aplicación y decidir cómo se comporta el sistema. En el ejemplo, HeroManager es el módulo de alto nivel porque organiza y coordina las acciones de los héroes, representando la "lógica de negocio" de este pequeño sistema.
Módulos de Bajo Nivel: Son aquellos que contienen los detalles concretos de implementación y son responsables de ejecutar tareas específicas. Estos módulos deberían ser utilizados por los módulos de alto nivel pero sin que éstos dependan directamente de ellos. En nuestro caso, Superman y Batman son los módulos de bajo nivel, ya que representan los detalles específicos de los héroes y de cómo ejecutan la acción save_the_day.

class EmailNotifier:

&#x20;   def send\_email(self, message):

&#x20;       print(f"Sending email with message: {message}")

class OrderProcessor:

&#x20;   def \_\_init\_\_(self):

&#x20;       self.notifier = EmailNotifier()

&#x20;   def process\_order(self, order):

&#x20;       \# Procesar el pedido (lógica ficticia)

&#x20;       print(f"Processing order: {order}")

&#x20;       self.notifier.send\_email("Order processed successfully.")

from abc import ABC, abstractmethod

\# Interfaz Notifier

class Notifier(ABC):

&#x20;   @abstractmethod

&#x20;   def send(self, message):

&#x20;       pass

\# Implementación concreta para enviar notificaciones por email

class EmailNotifier(Notifier):

&#x20;   def send(self, message):

&#x20;       print(f"Sending email with message: {message}")

\# Implementación concreta para enviar notificaciones por SMS

class SMSNotifier(Notifier):

&#x20;   def send(self, message):

&#x20;       print(f"Sending SMS with message: {message}")

\# OrderProcessor depende de la abstracción Notifier

class OrderProcessor:

&#x20;   def \_\_init\_\_(self, notifier: Notifier):

&#x20;       self.notifier = notifier

&#x20;   def process\_order(self, order):

&#x20;       \# Procesar el pedido (lógica ficticia)

&#x20;       print(f"Processing order: {order}")

&#x20;       self.notifier.send("Order processed successfully.")

\# Usando EmailNotifier

email\_notifier = EmailNotifier()

processor\_with\_email = OrderProcessor(email\_notifier)

processor\_with\_email.process\_order("Order #1")

\# Output:

\# Processing order: Order #1

\# Sending email with message: Order processed successfully.

\# Usando SMSNotifier

sms\_notifier = SMSNotifier()

processor\_with\_sms = OrderProcessor(sms\_notifier)

processor\_with\_sms.process\_order("Order #2")

\# Output:

\# Processing order: Order #2

\# Sending SMS with message: Order processed successfully.

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Qué es el principio de responsabilidad única

Procesador de pagos en Python con Stripe

Cómo aplicar SRP en un procesador de pagos con Stripe

Principio open-closed en Python

Clases abstractas y principio abierto-cerrado

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python

Principio de segregación de interfaces en SOLID

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias en SOLID

Principio de inversión de dependencias: servicio de pagos flexible

Reestructuración del proyecto

Reestructuración con módulos de Python y SOLID

Patrones de Diseño

Qué son los patrones de diseño: definición y categorías

Strategy Pattern con Python y setprocessor

Strategy Pattern para pagos en Python

Factory Pattern: centralizar creación de objetos

Patrón Factory para procesar pagos con match

Qué es el patrón Decorator

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder Pattern aplicado a un servicio de pagos

Observer Pattern en sistemas de eventos

Observer en sistemas de pagos con Python

Chain of Responsibility para validar pagos

Chain of Responsibility en servicios de pagos

Código funcional vs código mantenible en Python

Principio de inversión de dependencias en SOLID

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos