Principio de Inversión de Dependencias en Software

Clase 11 de 27 • Curso de Patrones de Diseño y SOLID en Python

Resumen

El principio de inversión de dependencias (Dependency Inversion Principle) es uno de los pilares en la construcción de software robusto, ya que busca disminuir la dependencia entre módulos de alto y bajo nivel, mejorando la flexibilidad y testabilidad del código. Este principio establece que tanto los módulos de alto como de bajo nivel deben depender de abstracciones, no de implementaciones concretas.

¿En qué consiste el principio de inversión de dependencias?

La definición formal indica que los módulos de alto nivel, que contienen la lógica de negocio, no deben depender de los módulos de bajo nivel, que gestionan los detalles de implementación. Ambos deben depender de abstracciones. Esto garantiza que los detalles de implementación dependan de las abstracciones y no al revés. Así, se facilita el cambio de implementaciones sin afectar al sistema principal.

¿Cómo se aplica este principio en un sistema real?

Un ejemplo claro es un gestor de notificaciones con una interfaz que define el método enviar mensaje. Este gestor es un módulo de alto nivel que no depende de cómo se implementa el envío de mensajes. Las clases de bajo nivel, como el notificador por email o por SMS, implementan esa interfaz, y el gestor puede cambiar de una a otra sin modificar su código. Esto muestra cómo el principio reduce el acoplamiento y facilita el mantenimiento.

¿Qué beneficios trae el principio de inversión de dependencias?

Modularidad: Al abstraer las implementaciones, las clases de alto nivel se mantienen independientes de los detalles.
Flexibilidad: Cambiar algoritmos o implementaciones es sencillo, ya que el sistema depende de interfaces y no de clases específicas.
Testabilidad: Facilita el uso de mocks en pruebas unitarias, simulando comportamientos sin depender de entornos complejos, como bases de datos.

¿Cuándo aplicar el principio de inversión de dependencias?

Cuando hay alto acoplamiento entre módulos de alto y bajo nivel, dificultando el mantenimiento.
Si se presentan problemas para cambiar implementaciones sin afectar el resto del sistema.
Al realizar pruebas unitarias complicadas por la dependencia directa de implementaciones concretas.
Cuando se dificulta la reutilización de componentes o el escalado del sistema.

Mario Alexander Vargas Celis

student•

El **Principio de Inversión de Dependencias** (Dependency Inversion Principle, DIP) establece que:

1. Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones (interfaces).

2. Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de abstracciones.

En esencia, el DIP sugiere que debemos evitar dependencias directas entre clases de alto y bajo nivel, favoreciendo la introducción de interfaces o abstracciones. Esto mejora la modularidad, la mantenibilidad y facilita el cambio de componentes del sistema.

### Ejemplo: Aplicación del DIP en Python

Supongamos que tenemos un sistema en el que una clase OrderProcessor gestiona pedidos y necesita enviar notificaciones cuando un pedido se procesa. Inicialmente, OrderProcessor depende de una implementación específica de notificación (EmailNotifier). Esto hace que OrderProcessor dependa de un detalle concreto, violando el DIP.

#### Ejemplo Incorrecto: Violación del DIP


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.")

Aquí, OrderProcessor depende directamente de EmailNotifier. Si quisiéramos cambiar el tipo de notificación (por ejemplo, usar notificaciones por SMS), tendríamos que modificar OrderProcessor, lo cual es una violación del DIP.

### Solución Correcta: Aplicando el DIP

Para aplicar el DIP, introducimos una abstracción (interfaz) Notifier, de la cual OrderProcessor depende, en lugar de depender de EmailNotifier directamente. Esto permite usar cualquier clase que implemente la interfaz Notifier, mejorando la flexibilidad y el mantenimiento.


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.")

### Explicación

- **Interfaz Notifier**: Es una abstracción que define el método send. OrderProcessor depende de esta interfaz, en lugar de una implementación concreta.

- **Clases EmailNotifier y SMSNotifier**: Ambas implementan la interfaz Notifier y proporcionan métodos específicos para enviar notificaciones.

- **Clase OrderProcessor**: Ahora depende de Notifier, no de EmailNotifier. Al pasar una instancia de Notifier al constructor de OrderProcessor, podemos cambiar el tipo de notificación sin modificar la clase OrderProcessor.

### Uso del Código

Podemos crear una instancia de OrderProcessor con cualquier implementación de Notifier, cumpliendo con el DIP.


\# 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.

### Ventajas de Aplicar el DIP

1. **Modularidad**: Podemos cambiar la implementación del servicio de notificación sin modificar la clase OrderProcessor.

2. **Facilidad de Testeo**: Podemos pasar una implementación de Notifier simulada (mock) a OrderProcessor para pruebas unitarias.

3. **Mantenibilidad y Extensibilidad**: Podemos añadir nuevas formas de notificación (por ejemplo, por WhatsApp) sin cambiar el código de OrderProcessor.

### Conclusión

El **Principio de Inversión de Dependencias** permite diseñar sistemas más flexibles y modulares al reducir las dependencias directas entre módulos de alto y bajo nivel. En este ejemplo, OrderProcessor depende de una abstracción (Notifier) en lugar de una implementación concreta, haciendo que sea fácil modificar o extender el comportamiento del sistema sin modificar el código central.

Wilbertson Mojica Cifuentes

student•

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

student•

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.