Código funcional vs código mantenible en Python
Contenido del curso
Principios SOLID
- 2
Qué es el principio de responsabilidad única
05:58 min - 3
Procesador de pagos en Python con Stripe
11:13 min - 4
Cómo aplicar SRP en un procesador de pagos con Stripe
25:19 min - 5
Principio open-closed en Python
02:39 min - 6
Clases abstractas y principio abierto-cerrado
14:46 min - 7
Principio de Liskov en S.O.L.I.D.
03:18 min - 8
Principio de sustitución de Liskov en Python
06:38 min - 9
Principio de segregación de interfaces en SOLID
02:33 min - 10
Segregación de interfaces en procesadores de pagos
09:05 min - 11
Principio de inversión de dependencias en SOLID
04:13 min - 12
Principio de inversión de dependencias: servicio de pagos flexible
05:56 min
Reestructuración del proyecto
Patrones de Diseño
- 14
Qué son los patrones de diseño: definición y categorías
03:54 min - 15
Strategy Pattern con Python y setprocessor
01:55 min - 16
Strategy Pattern para pagos en Python
10:58 min - 17
Factory Pattern: centralizar creación de objetos
03:04 min - 18
Patrón Factory para procesar pagos con match
11:06 min - 19
Qué es el patrón Decorator
03:06 min - 20
Patrón decorador en servicios de pagos
12:57 min - 21
Builder Pattern: construcción paso a paso
01:28 min - 22
Builder Pattern aplicado a un servicio de pagos
18:54 min - 23
Observer Pattern en sistemas de eventos
01:48 min - 24
Observer en sistemas de pagos con Python
11:11 min - 25
Chain of Responsibility para validar pagos
02:04 min - 26
Chain of Responsibility en servicios de pagos
16:27 min - 27
Código funcional vs código mantenible en Python
Viendo ahora
Código funcional vs código mantenible en Python
Resumen
Aplicar principios SOLID y patrones de diseño en Python transforma un script funcional en un sistema mantenible, escalable y flexible. Si construyes procesadores de pagos o cualquier servicio backend, esta guía te muestra cómo evolucionar tu código desde una clase monolítica hasta una arquitectura modular lista para crecer.
¿Cómo evoluciona un procesador de pagos al aplicar SOLID?
Al inicio existía una sola clase con un método procesar_transacción que cargaba con todo: validar la información, cobrar contra la pasarela de Stripe, notificar al usuario y registrar la transacción en un log. Funcionaba, sí, pero violaba casi todos los principios SOLID.
La reconstrucción avanzó paso a paso, desde el principio de responsabilidad única hasta el principio de inversión de dependencias. Cada principio fue empujando el código hacia clases con un propósito claro y dependencias inyectadas en lugar de acopladas.
¿Qué son los principios SOLID? Son cinco reglas de diseño orientado a objetos que ayudan a escribir código mantenible: responsabilidad única, abierto/cerrado, sustitución de Liskov, segregación de interfaces e inversión de dependencias.
¿Qué cambió en la estructura del código en Python?
El resultado final usa módulos de Python para separar responsabilidades y define una clase específica por comportamiento. Ya no hay una clase haciendo todo, sino piezas pequeñas que colaboran entre sí.
- Un módulo para validación de datos.
- Un módulo para procesamiento de pagos contra Stripe.
- Un módulo para notificaciones.
- Un módulo para logging de eventos.
Esa separación es la base para que el sistema pueda escalar sin que cada cambio rompa otro componente.
¿Qué patrones de diseño se aplicaron al procesador de pagos?
A los principios SOLID se sumaron varios patrones de diseño que resolvieron problemas concretos del flujo de pagos. Cada uno entró con una razón clara, no por adornar el código.
- Patrón builder: simplifica la instanciación de la clase principal, evitando constructores con demasiados parámetros.
- Patrón factory: elige el procesador de pagos correcto según las circunstancias del pago, sin que el cliente conozca la clase concreta.
- Decorador para logging: envuelve al servicio principal para registrar eventos sin modificar su lógica original.
- Cadena de responsabilidad: valida la información paso a paso antes de procesar el cobro, permitiendo agregar nuevas validaciones sin tocar el flujo central.
¿Para qué sirve el patrón factory en un procesador de pagos? Sirve para decidir, en tiempo de ejecución, qué procesador concreto se usa según el tipo de transacción, sin acoplar al cliente con una clase específica.
¿Cómo se comporta el código final al ejecutarse?
Al correr el sistema reconstruido, el flujo replica el comportamiento del algoritmo inicial pero con mucho mejor arquitectura. Valida la información, procesa la transacción, notifica a los servicios correspondientes, envía la confirmación, registra el evento y retorna.
La verificación en Stripe confirma el cierre del ciclo: el cargo se aplica a la tarjeta correcta por el monto correcto. El requisito original, hacer una transacción real con Stripe, se cumple, ahora con una base preparada para crecer.
¿Por qué código que funciona no siempre es código mantenible?
Que un programa corra hoy no garantiza que sobreviva mañana. Un código que ignora los principios SOLID y carece de patrones de diseño termina siendo frágil, difícil de modificar y limitado frente a alta transaccionalidad.
El procesador de pagos inicial funcionaba, pero no aguantaría escala. La versión final también será reemplazada algún día, porque todo software envejece. La diferencia está en cuánto tiempo y con qué facilidad puedes mantenerlo, extenderlo y adaptarlo mientras siga vivo.
¿Cuál es la diferencia entre código funcional y código mantenible? El código funcional cumple su tarea hoy; el mantenible permite agregar funcionalidades, corregir errores y escalar sin reescribirlo desde cero.
Si construiste tu propio procesador siguiendo el curso, cuéntame en los comentarios qué patrón te resultó más útil y qué refactor aplicarías ahora a tu código de trabajo.
