🧩 Patrones de diseño
¿Qué son?
Los patrones de diseño son soluciones probadas a problemas que aparecen una y otra vez cuando diseñas software. No es código que copias y pegas. Es más bien una receta: te dice los ingredientes, los pasos y el resultado esperado, pero tú la adaptas a tu cocina.
Los definieron cuatro tipos (conocidos como la Gang of Four o GoF) en 1994, en el libro que sigue siendo la biblia del tema. Desde entonces, la industria entera los usa como vocabulario común.
Dicho en cristiano: un patrón de diseño es una forma inteligente de resolver un problema que ya ha resuelto mucha gente antes que tú. No reinventes la rueda.
¿Y por qué tendría que usarlos?
Porque estos prototipos han sido implementados miles de veces en proyectos reales. Son garantía de que tu código acabe siendo:
- Reutilizable: La misma solución sirve en contextos completamente diferentes.
- Fácil de entender: Dices “esto es un Observer” y cualquier desarrollador sabe de qué hablas. Sin explicaciones de 20 minutos.
- Mantenible: Código bien estructurado = menos dolores de cabeza cuando toca modificar algo 6 meses después.
- Escalable: Los patrones están pensados para que el software crezca sin convertirse en un monstruo.
Y esto último es clave: los patrones te dan un lenguaje común. Cuando dices “aquí uso un Factory Method”, tu compañero de equipo ya sabe la estructura, las ventajas y las limitaciones. No hace falta explicar cada decisión desde cero.
El libro: la biblia de los patrones
Todo viene de Design Patterns: Elements Of Reusable Object-Oriented Software (1994), escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Definieron 23 patrones agrupados en tres categorías. Sigue siendo referencia obligada, aunque hoy en día hay muchos más recursos (y más digeribles) para aprenderlos.
Los tres tipos de patrones
Según el catálogo GoF, los patrones se agrupan en tres categorías según el tipo de problema que resuelven:
Se ocupan de cómo se crean los objetos. Ocultan la lógica de instanciación para que tu código no dependa de clases concretas. Ejemplo: necesitas crear objetos sin saber exactamente qué tipo serán hasta tiempo de ejecución.
Se ocupan de cómo se componen las clases y objetos para formar estructuras más grandes. Ejemplo: necesitas que dos interfaces incompatibles trabajen juntas, o simplificar el acceso a un subsistema complejo.
Se ocupan de cómo se comunican los objetos entre sí y cómo se reparten responsabilidades. Ejemplo: necesitas que varios objetos reaccionen cuando otro cambia de estado, sin acoplamiento directo.
Patrones creacionales
Centrados en el proceso de crear objetos. Ocultan la lógica de instanciación y te dan flexibilidad para decidir qué se crea, cómo y cuándo.
| Patrón | ¿Qué hace? | Caso típico |
|---|---|---|
| Singleton | Garantiza que una clase tenga una única instancia en toda la aplicación | Conexión a base de datos, logger, configuración global |
| Factory Method | Delega la creación de objetos a subclases, sin especificar la clase exacta | Crear notificaciones (email, SMS, push) según el contexto |
| Abstract Factory | Crea familias de objetos relacionados sin depender de clases concretas | UI multiplataforma (botones, inputs, modales de Windows vs macOS) |
| Builder | Construye objetos complejos paso a paso | Generar consultas SQL, construir informes PDF, configurar objetos con muchos parámetros |
| Prototype | Crea objetos clonando instancias existentes | Duplicar configuraciones, clonar documentos, copiar estados de juego |
Patrones estructurales
Se enfocan en cómo se componen las clases y objetos para formar estructuras más grandes y flexibles.
| Patrón | ¿Qué hace? | Caso típico |
|---|---|---|
| Adapter | Hace que interfaces incompatibles trabajen juntas | Integrar un servicio de pago antiguo con tu API moderna |
| Decorator | Añade funcionalidad extra a un objeto dinámicamente | Añadir logging, caché o compresión a un servicio sin modificarlo |
| Composite | Trata objetos individuales y grupos de forma uniforme | Menús con submenús, carpetas con archivos, organigramas |
| Facade | Proporciona una interfaz simple a un subsistema complejo | Un método procesarPedido() que por dentro llama a stock, pago, envío y email |
| Proxy | Proporciona un sustituto que controla el acceso a otro objeto | Lazy loading de imágenes, control de permisos, caché transparente |
| Bridge | Separa una abstracción de su implementación | Notificaciones (urgente/normal) por diferentes canales (email/SMS/Slack) |
| Flyweight | Minimiza el uso de memoria compartiendo datos comunes | Renderizar miles de árboles en un videojuego, caracteres en un editor de texto |
Patrones de comportamiento
Se centran en la comunicación entre objetos y en cómo se reparten las responsabilidades.
| Patrón | ¿Qué hace? | Caso típico |
|---|---|---|
| Observer | Define una dependencia uno-a-muchos: cuando un objeto cambia, los demás se enteran | Notificaciones en tiempo real, eventos de un blog, listeners del DOM |
| Strategy | Define una familia de algoritmos intercambiables | Métodos de pago (PayPal, tarjeta, Bizum), cálculo de envío |
| Command | Encapsula una petición como un objeto | Undo/Redo en editores, colas de tareas, transacciones |
| Interpreter | Define una gramática y la interpreta | Evaluar expresiones matemáticas, parsear reglas de negocio, SQL simplificado |
| State | Un objeto cambia de comportamiento según su estado interno | Pedidos (pendiente→pagado→enviado), reproductor multimedia, semáforos |
| Mediator | Centraliza la comunicación entre objetos | Chat rooms, torres de control de aeropuerto, formularios complejos |
| Iterator | Recorre una colección sin exponer su estructura interna | Recorrer listas, árboles, resultados de base de datos |
| Chain of Responsibility | Pasa una petición por una cadena de manejadores | Middleware de un framework, pipeline de validaciones, soporte técnico por niveles |
| Memento | Captura y restaura el estado interno de un objeto | Ctrl+Z en editores de texto, snapshots de configuración, checkpoints de juegos |
| Template Method | Define el esqueleto de un algoritmo en la clase base, las subclases rellenan los pasos | Tests (setUp→execute→assert→tearDown), frameworks web, generación de informes |
| Visitor | Añade operaciones nuevas a una jerarquía sin modificar sus clases | Compiladores (AST), exportadores multi-formato, validadores de documentos |
¿Cómo elijo el patrón correcto?
No hay una fórmula mágica, pero puedes hacerte estas preguntas:
¿Necesitas controlar cómo y cuándo se crean los objetos? ¿Hay lógica compleja de instanciación? ¿Necesitas flexibilidad para decidir el tipo en tiempo de ejecución? → Patrón creacional
¿Necesitas que clases diferentes trabajen juntas? ¿Quieres simplificar una interfaz compleja? ¿Necesitas añadir comportamiento sin modificar clases? → Patrón estructural
¿Necesitas que objetos reaccionen a cambios de otro? ¿Quieres intercambiar algoritmos? ¿Necesitas desacoplar quién envía una petición de quién la procesa? → Patrón de comportamiento
A veces la solución más simple es la mejor. Si un if/else resuelve el problema y el código es claro, no fuerces un patrón. Un patrón mal aplicado es peor que no usar ninguno.
Errores comunes al aprender patrones
Cuando empiezas a estudiar patrones de diseño, hay trampas en las que cae casi todo el mundo:
1. Querer meter patrones en todas partes. El martillo de oro. Aprendes Singleton y de repente todo necesita ser Singleton. Aprendes Observer y hasta el “Hola mundo” tiene eventos. Los patrones son herramientas, no objetivos.
2. Aplicar un patrón sin entender el problema. Si no entiendes bien por qué existe el patrón, no vas a saber cuándo usarlo. Antes de implementar un Strategy, pregúntate: ¿realmente tengo algoritmos intercambiables o simplemente tengo un if/else que funciona perfecto?
3. Confundir patrones similares. Factory Method vs Abstract Factory, Strategy vs State, Decorator vs Proxy… Muchos se parecen en estructura pero resuelven problemas distintos. Lee bien las diferencias antes de elegir.
4. Pensar que los patrones son la única forma correcta. Los patrones GoF tienen más de 30 años. Son muy útiles, pero no son dogma. Hay problemas que se resuelven mejor con enfoques funcionales, con composición simple o con las herramientas que te da tu framework.
Principios SOLID y patrones de diseño
Los patrones de diseño y los principios SOLID van de la mano. De hecho, la mayoría de patrones existen precisamente para cumplir uno o varios principios SOLID:
| Principio | ¿Qué dice? | Patrones que lo aplican |
|---|---|---|
| SRP | Cada clase, una sola responsabilidad | Visitor, Strategy, Command, Observer, Mediator |
| OCP | Abierto a extensión, cerrado a modificación | Strategy, Decorator, Observer, Visitor, Template Method |
| LSP | Las subclases pueden sustituir a la clase base | Factory Method, Template Method, State, Strategy |
| ISP | Interfaces pequeñas y específicas | Adapter, Proxy, Observer, Iterator |
| DIP | Depende de abstracciones, no de implementaciones | Factory Method, Abstract Factory, Bridge, Strategy, Observer |
No necesitas memorizar esta tabla. Cuando leas cada patrón en detalle (están todos enlazados arriba), verás cómo aplican estos principios de forma natural.
Conclusión
Los patrones de diseño no son magia ni bala de plata. Son herramientas que, usadas en el momento adecuado, hacen que tu código sea más limpio, más fácil de entender y más fácil de mantener.
Lo importante:
- No los fuerces. Si tu código funciona bien y es claro, no necesitas meter un patrón a la fuerza.
- Entiende el problema primero. El patrón viene después, como solución, no como punto de partida.
- Aprende el vocabulario. Solo con saber que existen y qué resuelven ya tienes una ventaja enorme cuando trabajes en equipo.
- Practica. Lee los posts individuales de cada patrón (están todos enlazados en las tablas de arriba), implementa los ejemplos y experimenta.
Los 23 patrones del catálogo GoF llevan más de 30 años funcionando. No están ahí por casualidad. Pero recuerda: el mejor código no es el que usa más patrones, sino el que resuelve el problema de la forma más simple y clara posible.
¡Un saludo y nos vemos en los bares! 🍻
🧠 Pon a prueba lo aprendido
1. ¿Qué es un patrón de diseño?
2. ¿En cuántas categorías agrupa el catálogo GoF los patrones de diseño?
3. ¿Qué tipo de problema resuelven los patrones creacionales?
4. ¿Cuál es una ventaja clave de conocer los patrones de diseño?
5. ¿Cuál es un error común al aprender patrones de diseño?
6. Si necesitas que dos interfaces incompatibles trabajen juntas, ¿qué tipo de patrón buscarías?
7. ¿Qué relación hay entre los principios SOLID y los patrones de diseño?
8. ¿Cuándo NO deberías usar un patrón de diseño?