- ¿Qué son los patrones de diseño?
- ¿Y qué papel juega el polimorfismo?
- ¿Qué riesgos hay al aplicar patrones sin comprenderlos?
Vamos a comenzar una nueva etapa del curso: los patrones de diseño. A lo largo de las siguientes lecciones veremos varios de ellos, pero antes necesitamos entender qué son, para qué sirven y cómo se relacionan con la programación orientada a objetos (POO).
¿Qué son los patrones de diseño?
Aunque no dependen exclusivamente de la POO, la mayoría de los patrones se entienden mejor si ya conoces conceptos como clases, herencia o polimorfismo. Por eso es importante dominar esas bases antes de aplicar patrones de forma consciente.
¿Y qué papel juega el polimorfismo?
Este principio es clave para muchos patrones de diseño. Aquí tienes algunos ejemplos de patrones que se basan directamente en el polimorfismo:
| Patrón | ¿Para qué se usa? |
|---|---|
| Estrategia | Para variar algoritmos sin cambiar el código que los usa |
| Fábrica abstracta | Para crear grupos de objetos relacionados |
| Adaptador | Para adaptar una interfaz sin cambiar el código original |
| Compuesto (Composite) | Para trabajar como si un grupo de objetos fuera uno solo |
| Decorador | Para agregar funcionalidades a un objeto sin modificar su código |
| Observador | Para reaccionar automáticamente a cambios en otros objetos |
| Cadena de responsabilidad | Para pasar una petición por una secuencia de objetos hasta que uno responda |
| Estado | Para cambiar el comportamiento de un objeto según su estado actual |
| Método plantilla | Para definir el esqueleto de un algoritmo pero delegar partes a subclases |
| Visitante | Para aplicar operaciones a objetos sin cambiar sus clases |
¿Qué riesgos hay al aplicar patrones sin comprenderlos?
Ejemplos de antipatrones comunes
| Nombre | ¿Por qué es un mal hábito? |
|---|---|
| Objeto Dios (God Object) | Tiene demasiadas responsabilidades; todo pasa por él |
| Singleton | Solo permite una instancia; puede dificultar las pruebas y el mantenimiento |
| Código duplicado | Copiar y pegar lógica sin abstraer |
Por ejemplo, el patrón Singleton —muy popular antes— hoy se considera un antipatrón en muchos casos, porque complica las pruebas y limita la flexibilidad. Mira este ejemplo:
class BaseDeDatos:
_instancia = None
def __new__(cls):
if not cls._instancia:
cls._instancia = super().__new__(cls)
print("Conectando a la base de datos...")
return cls._instancia
db1 = BaseDeDatos()
db2 = BaseDeDatos()
print(db1 is db2) # True, ambas variables apuntan al mismo objeto
Este código garantiza una sola instancia, lo cual puede parecer útil. Pero si más adelante quieres simular conexiones distintas (por ejemplo, en pruebas), este diseño te limita gravemente. Por eso muchos desarrolladores hoy evitan el Singleton.
Este tipo de errores son comunes cuando aplicamos soluciones sin entender bien el contexto. Por eso, antes de copiar un patrón, es clave preguntarse: ¿cuál es el problema que estoy resolviendo?
Resumen
- Los patrones de diseño son soluciones reutilizables a problemas comunes en el desarrollo de software.
- Muchos patrones comparten una estructura: una interfaz común y varias clases que representan distintos comportamientos.
- Copiar patrones sin comprenderlos puede llevar a errores, como crear antipatrones o añadir complejidad innecesaria.
Materiales adicionales
Para acceder completo a curso necesitas un plan básico
El plan básico te dará acceso completo a todos los cursos, ejercicios y lecciones de Códica, proyectos y acceso de por vida a la teoría de las lecciones completadas. La suscripción se puede cancelar en cualquier momento.
