Veintitrés patrones son demasiados para abordarlos en desorden. Por eso el Gang of Four los organizó en un mapa con dos ejes —el propósito del patrón y su ámbito— que sigue siendo la forma estándar de navegar el catálogo. Esta lección es exactamente eso: el mapa del territorio que recorrerás en los módulos 2, 3 y 4. Verás las tres familias (creacionales, estructurales y de comportamiento), qué pregunta responde cada una, la tabla completa de los 23 patrones con su propósito en una línea, y una mención a las familias que quedaron fuera del GoF y que visitaremos en el módulo 6. No desarrollaremos ningún patrón individual: hoy toca orientarse, no excavar.

1. Los dos ejes de clasificación del GoF
2. Primer eje: el propósito (las tres familias)
3. Los 23 patrones, familia a familia
4. Segundo eje: el ámbito (clase frente a objeto)
5. Más allá del GoF: otras familias de patrones
6. El mapa como itinerario del curso

El libro Design Patterns clasifica sus 23 patrones con dos criterios ortogonales:

• Propósito (purpose): ¿qué tipo de problema resuelve el patrón? Da lugar a las tres familias: creacionales (cómo se crean los objetos), estructurales (cómo se componen) y de comportamiento (cómo colaboran y se reparten responsabilidades).
• Ámbito (scope): ¿el patrón opera sobre clases (relaciones fijadas en compilación, vía herencia) o sobre objetos (relaciones establecidas en ejecución, vía composición)?

El primer eje es el que todo el mundo usa para hablar de patrones y el que estructura este curso; el segundo es más sutil pero muy revelador, y lo veremos en la sección 4.

Una intuición útil para recordar las tres familias con PideYa: piensa en el ciclo de vida de los objetos de un sistema. Primero hay que crearlos (¿quién hace el new de la pasarela de pago adecuada?), luego organizarlos en estructuras mayores (¿cómo se monta un menú que contiene platos y otros menús?), y finalmente hacerlos colaborar (¿cómo se entera el repartidor de que el pedido cambió de estado?). Creación → estructura → comportamiento.

Pregunta que responden: ¿cómo crear objetos sin que el código quede acoplado a las clases concretas que instancia, y cómo controlar cuántas instancias existen y cómo se montan las complejas?

Como vimos al estudiar los principios de diseño, el new es el punto donde inevitablemente se nombra una clase concreta. Los creacionales existen para aislar y centralizar esos puntos, de modo que el resto del sistema programe contra interfaces. En PideYa, son los patrones que responderán a "¿quién decide si el pago se procesa con la pasarela de tarjeta o con PayPal?" o "¿cómo se construye un pedido con líneas, descuentos, dirección y propina sin un constructor de diez parámetros?".

Pregunta que responden: ¿cómo combinar clases y objetos en estructuras mayores que sigan siendo flexibles y eficientes?

Son los patrones de la composición: envolver un objeto para añadirle algo, adaptar una interfaz ajena a la que tu código espera, tratar igual a un elemento y a un grupo de elementos, o dar una fachada simple a un subsistema enrevesado. En PideYa aparecerán cuando integremos la API de un proveedor externo de pagos que no encaja con nuestras interfaces, o cuando modelemos cartas que contienen secciones que contienen platos.

Pregunta que responden: ¿cómo repartir responsabilidades entre objetos y organizar la comunicación entre ellos para que cada uno haga lo suyo sin acoplarse al resto?

Es la familia más numerosa, porque la colaboración es lo más difícil de diseñar. Aquí viven los patrones que resuelven el problema de las notificaciones de Pedido que vimos en la primera lección, los que modelan el ciclo de estados de un pedido (recibido → en preparación → en reparto → entregado) y los que permiten intercambiar algoritmos (estrategias de cálculo de gastos de envío) en tiempo de ejecución.

Aquí tienes el catálogo completo. No intentes memorizarlo hoy: úsalo como índice al que volver. Cada patrón tiene su lección propia en los módulos 2–4.

Recuento: 5 + 7 + 11 = 23. Como referencia de importancia práctica: no todos pesan igual en el día a día. Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Observer, Strategy, Template Method y Command aparecen constantemente; Interpreter o Flyweight son mucho más ocasionales. En las lecciones de cada patrón y en las comparativas de cierre de cada módulo (02-07, 03-09, 04-13) matizaremos este peso relativo.

El segundo criterio del GoF pregunta cómo establece el patrón sus relaciones:

• Ámbito de clase: la relación clave se fija mediante herencia, en tiempo de compilación. Una vez compilado, el comportamiento está decidido.
• Ámbito de objeto: la relación clave se establece mediante composición: referencias entre objetos que pueden cambiarse en tiempo de ejecución.

Dos observaciones valiosas de esta tabla:

1. La inmensa mayoría de patrones son de ámbito de objeto. Es la máxima "favorece la composición sobre la herencia" hecha estadística: de 23 patrones, solo un puñado se apoya en herencia como mecanismo central.
2. Hay parejas de patrones que resuelven problemas parecidos, uno por clase y otro por objeto (lo verás, por ejemplo, entre Template Method y Strategy, o entre las dos variantes de Adapter). Comprender el eje de ámbito te dará el criterio para elegir: la herencia es más simple pero rígida; la composición, más flexible pero con más piezas.

El mapa del GoF cubre el diseño de clases y objetos dentro de una aplicación orientada a objetos. Como vimos en la lección de historia, la comunidad siguió cosechando patrones en otros niveles. Las familias que conviene tener en el radar:

• Patrones arquitectónicos: deciden la forma global del sistema, no de unas clases (capas, MVC, microkernel, broker...). Operan a una escala mayor que el GoF.
• Patrones de concurrencia: coordinan hilos y recursos compartidos (productor-consumidor, thread pool, reactor...).
• Patrones de empresa e integración: persistencia, transacciones y mensajería entre sistemas (Repository, Unit of Work, colas y canales...).
• Patrones de microservicios y sistemas distribuidos: resiliencia y coordinación entre servicios remotos (API Gateway, Circuit Breaker, Saga...).

Todas estas familias se tratan en el módulo 6 (arquitecturas modernas, microservicios, sistemas distribuidos y concurrencia); aquí basta con que sitúes cada una en su escala:

Esta clasificación no es solo teoría: es literalmente el índice de lo que viene. Tu itinerario:

Cada módulo de patrones sigue además el mismo ritmo: una introducción a la familia, una lección por patrón (con el problema planteado en PideYa) y una comparativa final para elegir entre patrones parecidos. El orden creacionales → estructurales → de comportamiento no es casual: replica el ciclo natural crear → componer → colaborar, y cada familia se apoya en las anteriores.

• Intentar memorizar los 23 de golpe. Es inútil y desmoralizante. Hoy solo necesitas las tres preguntas de familia (¿creación? ¿estructura? ¿colaboración?) y saber que la tabla existe para consultarla.
• Tratar la familia como un cajón rígido. Algunos patrones tienen un pie en dos mundos y en la práctica se combinan constantemente (una fábrica que devuelve estrategias, un composite recorrido por un visitor). La clasificación orienta; no encierra.
• Ignorar el eje de ámbito. Casi todo el mundo conoce las tres familias y casi nadie el eje clase/objeto, que es justo el que explica por qué existen parejas de patrones "gemelos" y cuál elegir. Tenerlo presente te dará ventaja en los módulos 3 y 4.
• Creer que el mapa GoF es todo el territorio. Si solo conoces los 23, intentarás resolver con ellos problemas que pertenecen a otra escala (arquitectura, distribución, concurrencia). Parte del criterio es saber cuándo tu problema ni siquiera es de esta familia; el módulo 6 existe para eso.
• Consejo: imprime o guarda las tres tablas de la sección 3. Volver a ellas tras estudiar cada patrón ("¿sigo de acuerdo con esta línea de resumen?") es una técnica de repaso excelente: cuando todas las líneas te parezcan obvias, dominarás el catálogo.

Para cada problema, indica qué familia de patrones (creacional, estructural o de comportamiento) lo abordaría. No nombres patrones concretos: razona solo por la naturaleza del problema.

1. Cuando un pedido pasa a "entregado", deben enterarse el cliente, el sistema de fidelización y las estadísticas.
2. El proveedor externo de mapas tiene una API con métodos y tipos que no encajan con las interfaces de rutas de PideYa.
3. Montar un objeto Pedido válido exige combinar carrito, dirección, franja horaria, descuentos y propina, con muchas combinaciones opcionales.
4. La carta de un restaurante contiene secciones, que contienen platos o sub-secciones, y hay que calcular precios y alérgenos sobre el conjunto.
5. Según el país, PideYa debe usar un juego completo y coherente de: pasarela de pago, calculadora de impuestos y formateador de tiques.

Sin conocer aún los patrones, razona: ¿por qué un patrón de ámbito de objeto permite cambiar el comportamiento en tiempo de ejecución y uno de ámbito de clase no? Ilústralo con el ejemplo del Repartidor y su Vehiculo de la lección de principios.

Indica si cada problema pertenece al territorio del GoF o a otra familia de patrones (arquitectónica, concurrencia, distribuidos/empresa):

1. Decidir si PideYa se estructura como monolito en capas o como microservicios.
2. Evitar que dos hilos que procesan pagos simultáneos corrompan el saldo del monedero.
3. Hacer que la clase Pedido no conozca los detalles de los canales de notificación.
4. Reintentar y aislar las llamadas al servicio externo de pagos cuando este se degrada.

Solución 1:

1. De comportamiento: es un problema de comunicación/colaboración entre objetos (notificar cambios sin acoplarse).
2. Estructural: hay que hacer encajar interfaces incompatibles componiendo/envolviendo objetos existentes.
3. Creacional: el problema es cómo construir un objeto complejo con muchas variantes.
4. Estructural: es una composición de objetos en árbol tratando uniformemente partes y conjuntos.
5. Creacional: hay que crear familias coherentes de objetos relacionados según una condición (el país).

Solución 2: en un patrón de ámbito de clase, la relación se establece por herencia: qué comportamiento tiene cada clase queda decidido al compilar, y un objeto no puede cambiar de clase una vez creado. En uno de ámbito de objeto, la relación es una referencia a otro objeto, y una referencia se puede reasignar en cualquier momento. Con el ejemplo: si modelamos RepartidorEnMoto extends Repartidor, un repartidor "es" de moto para siempre (habría que destruir el objeto y crear otro). Si Repartidor tiene un Vehiculo, basta repartidor.asignarVehiculo(new Bicicleta()) a mitad de turno: el comportamiento (tiempos de entrega) cambia en caliente sin cambiar de objeto.

Solución 3:

1. Arquitectónica: decide la forma global del sistema, una escala por encima del diseño de clases (módulo 6).
2. Concurrencia: coordinación de hilos y estado compartido (módulo 6).
3. GoF: diseño de colaboración entre clases dentro de la aplicación (módulo 4).
4. Distribuidos/microservicios: resiliencia frente a servicios remotos degradados (módulo 6).

Ya tienes el mapa completo: dos ejes de clasificación (propósito y ámbito), tres familias con su pregunta característica —creacionales: ¿cómo nacen los objetos?; estructurales: ¿cómo se componen?; de comportamiento: ¿cómo colaboran?—, la tabla de los 23 patrones del GoF como índice de consulta, y la ubicación de las familias modernas (arquitectura, concurrencia, empresa, distribuidos) que esperan en el módulo 6. También sabes leer el detalle que casi todos pasan por alto: el eje clase/objeto, que explica por qué la composición domina el catálogo.

Antes de lanzarnos al primer patrón queda una última parada, quizá la que más madurez profesional aporta: pesar honestamente lo que los patrones dan y lo que cuestan, y aprender a decidir cuándo usarlos y cuándo no. Es la lección que cierra este módulo: Ventajas y Desventajas de Usar Patrones de Diseño.