Patrones de Diseño y Principios SOLID
Patrones de Diseño y Principios SOLID en Python
Principios SOLID
Principio de Responsabilidad Única (SRP) en Python
Procesador de Pagos con Stripe en Python
Aplicar el Principio de Responsabilidad Única (SRP)
Principio Abierto/Cerrado (OCP) en Python
Aplicar el Principio Abierto/Cerrado (OCP)
Principio de Sustitución de Liskov (LSP) en Python
Aplicar el Principio de Sustitución de Liskov (LSP)
Principio de Segregación de Interfaces (ISP) en Python
Aplicar el Principio de Segregación de Interfaces (ISP)
Principio de Inversión de Dependencias (DIP) en Python
Aplicar el Principio de Inversión de Dependencias (DIP)
Reestructuración del proyecto
Reestructuración de un proyecto en Python
Patrones de Diseño
Introducción a los Patrones de Diseño
Patrón Strategy en Python
Implementando el Patrón Strategy
Patrón Factory en Python
Implementando el Patrón Factory
Patrón Decorator en Python
Implementando el Patrón Decorador: Mejora tu Servicio de Pagos
Patrón Builder en Python
Implementando el Patrón Builder: Construye Servicios de Pago
Patrón Observer en Python
Implementando el Patrón Observer
Patrón Chain of Responsibility en Python
Implementando el Patrón Chain of Responsibility: Flujo Eficiente de Validaciones
Patrones de Diseño y Principios SOLID en un Procesador de Pagos
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
El principio de inversión de dependencias es clave para mejorar la arquitectura del código, y este ejemplo sobre el servicio de pagos lo ilustra perfectamente. En lugar de que la clase de alto nivel dependa de detalles de las clases de bajo nivel, se trabaja con abstracciones, lo que permite mayor flexibilidad al añadir nuevas funcionalidades.
Sí, el código cumple con el principio desde el momento en que el servicio de pagos (clase de alto nivel) no depende directamente de los detalles de los procesadores de pagos, validadores o notificadores, sino de interfaces o protocolos. Esto significa que, si alguna de las implementaciones cambia, el servicio de alto nivel no requiere modificaciones, ya que interactúa únicamente con las abstracciones.
Aunque la implementación está alineada con el principio de inversión de dependencias, hay un detalle por mejorar: las clases de alto nivel aún instancian clases de bajo nivel dentro de sus atributos, como los validadores o el logger. Para eliminar esta dependencia, se recomienda remover esas “default factories” y en su lugar, inyectar todas las dependencias desde fuera del servicio. Esto garantizaría una mayor adherencia al principio.
El código muestra claramente cómo se instancian las dependencias antes de crear el servicio de pagos. Se crea el procesador de pagos de Stripe, un notificador de email, los validadores de clientes y pagos, así como el logger. Luego, se pasa cada dependencia al PaymentService
, asegurando que el servicio de alto nivel no conozca los detalles internos de las clases de bajo nivel.
La inyección de dependencias facilita la flexibilidad, ya que permite cambiar las implementaciones sin modificar el servicio principal. Si en lugar de Stripe se requiere otro procesador o un notificador distinto como SMS, el código solo necesita ajustar las instancias que se pasan al servicio, sin afectar el código principal.
Aportes 5
Preguntas 2
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?