Principio open-closed 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
Viendo ahora - 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
03:19 min
Principio open-closed en Python
Resumen
El principio open-closed es la "O" dentro de SOLID y plantea que el software debe estar abierto para su extensión, pero cerrado para su modificación. Si escribes código en Python o cualquier lenguaje orientado a objetos, entender este principio te permite agregar funcionalidades sin romper lo que ya funciona.
¿Qué significa abierto para extensión y cerrado para modificación?
El software cambia todo el tiempo. Agregas funcionalidades, creas nuevas, eliminas otras que ya no sirven. El principio open-closed responde justo a esa naturaleza cambiante.
Estar abierto para la extensión quiere decir que puedes sumar comportamientos nuevos sin tocar la base de código anterior. Para lograrlo, te apoyas en interfaces, abstracciones y polimorfismo, que en Python ya vienen integrados al lenguaje.
Estar cerrado para la modificación significa lo contrario: evitas cambios al código que ya probaste y validaste. Esto promueve el encapsulamiento y la estabilidad del sistema completo.
¿Qué es el principio open-closed? Es una regla de diseño que indica que tu código debe permitir agregar funcionalidades nuevas mediante extensión, sin necesidad de modificar el código existente que ya funciona.
¿Por qué importa este principio en el desarrollo de software?
La industria casi siempre te pide agregar funcionalidades en tiempos muy ajustados. Y aquí viene lo interesante: el software es la forma en la que las empresas crean valor, así que si tu código se mueve rápido y a la vez mantiene estabilidad, la empresa se beneficia directo.
Los beneficios concretos son dos:
- Menos errores, porque no tocas lo que ya está probado.
- Actualizaciones mucho más fáciles, porque solo extiendes.
Con este principio puedes responder rápido a cambios de requisitos sin romper lo existente, y lo nuevo se integra de forma coherente con lo anterior.
¿Cuándo aplicar el principio open-closed?
Lo aplicas cuando necesitas extender el funcionamiento sin modificar el código existente. Un caso típico es un procesador de pagos: si hoy tu sistema trabaja con Stripe y mañana quieres sumar otra pasarela, no deberías reescribir la lógica que ya funciona, sino extenderla.
Lo mismo pasa con notificaciones. Si tu sistema envía correos electrónicos y quieres agregar mensajes de texto, el open-closed te permite sumar ese canal sin tocar el flujo original.
¿Cuándo conviene usar open-closed? Cuando tu empresa tiene cambios frecuentes de requisitos o cuando necesitas agregar variantes de una funcionalidad ya existente, como nuevas pasarelas de pago o canales de notificación.
¿Cómo se relaciona con interfaces y polimorfismo?
Las interfaces y las abstracciones son las herramientas que hacen posible este principio. Defines un contrato general y luego cada nueva implementación lo cumple a su manera.
El polimorfismo te deja intercambiar esas implementaciones sin que el resto del sistema lo note. En Python, esto es natural al lenguaje, así que no necesitas estructuras adicionales para aplicarlo.
¿Qué beneficios trae al equipo y a la empresa?
Cuando aplicas open-closed de forma consistente, tu equipo gana en velocidad y confianza. Algunos puntos clave:
- Reduces la cantidad de bugs introducidos en cada cambio.
- Mantienes estable el código probado y validado.
- Aceleras la respuesta a nuevos requisitos del negocio.
- Facilitas que varias personas trabajen en paralelo sobre la misma base.
Esa combinación de rapidez y estabilidad es justo lo que diferencia a un equipo que entrega valor sostenido de uno que vive apagando incendios.
¿Cómo aplicarías el principio open-closed al procesador de pagos? ¿Y cómo lo has usado en tu día a día como desarrollador? Déjamelo en los comentarios.
