Once patrones en once lecciones: la familia más numerosa del catálogo, y también la más confundible — media docena de sus miembros comparten diagrama y se distinguen solo por la intención. Esta lección es el mapa final del módulo: la tabla completa, los cinco careos que resuelven el 90% de las dudas reales, un flowchart de decisión, las combinaciones que trabajan en equipo, y el repaso de qué quedó instalado en cada rincón de PideYa. Al terminarla, el catálogo GoF entero —creacionales, estructurales y de comportamiento— estará en tu caja de herramientas.

1. La tabla de los once
2. Los pares que se confunden, frente a frente
3. Guía de decisión
4. Combinaciones frecuentes
5. El módulo 4 en el mapa de PideYa
6. Ejercicios y conclusión
7. Cierre: el catálogo está completo

La columna "reifica" no es adorno: es el resumen del módulo. Los once aplican el mismo movimiento —convertir en objeto un aspecto de la conducta— y se distinguen por qué convierten.

Gemelos estructurales (contexto que delega en una interfaz con variantes); intención opuesta:

Prueba del algodón: si el objeto delegado se sustituye a sí mismo desde dentro, es State; si lo eligen desde fuera y las variantes no forman ciclo de vida, es Strategy.

Ambos encapsulan "código en un objeto":

Prueba del algodón: mira la firma. Si el método no necesita argumentos porque el objeto ya lleva la petición completa dentro, es Command; si recibe los datos en cada llamada, es Strategy.

Los dos desacoplan comunicación:

Prueba del algodón: ¿el que avisa necesita que alguien decida qué pasa después (Mediator), o solo que quien quiera se entere (Observer)?

El careo herencia/composición:

Prueba del algodón: ¿necesitas cambiar la variante en caliente o combinar ejes? Composición (Strategy). ¿Flujo fijo, variantes pocas y estables que comparten contexto? Plantilla.

El careo entre familias (lo prometimos en el módulo 3): ambos son objetos enlazados con la misma interfaz que delegan al siguiente.

Prueba del algodón: ¿algún elemento puede legítimamente cortar la cadena? Chain. ¿Todos aportan siempre su capa? Decorator.

El árbol de preguntas para orientarse (como toda guía: brújula, no ley — confirma después contra el careo correspondiente):

Y el recordatorio de siempre, herencia de la lección de la balanza: la primera opción válida es ninguno. Un if, una llamada directa o un enum siguen siendo la respuesta correcta cuando el síntoma no ha aparecido.

Los patrones de comportamiento trabajan en equipo mejor que ninguna otra familia:

• Command + Memento: el dúo del undo robusto — inversa cuando es simétrica y barata, foto cuando la inversa miente. El PanelGestion apila comandos; los comandos difíciles guardan mementos de su receiver.
• Observer + Mediator: la CentralReparto puede enterarse de los cambios de estado del pedido como un observador más (transitarA notifica) y dirigir la reacción como mediadora — difusión para enterarse, protocolo para actuar.
• Composite + Iterator + Visitor: el trío de las estructuras — Composite define el árbol de la carta, Iterator lo recorre sin exponerlo, Visitor le añade operaciones sin tocarlo. Tres lecciones, una sola carta.
• State + Observer: State autoriza las transiciones del pedido; Observer difunde las que ocurren. Conectados en un solo punto: transitarA.
• Mediator + Strategy: el mediador orquesta; sus criterios variables (asignación de repartidor) son estrategias inyectadas.
• Template Method + Strategy/Bridge: el flujo fijo por herencia, los ejes que cambian en caliente por composición — el ejercicio final de Template Method sobre las Notificacion.
• Chain + Command: por la cadena pueden viajar comandos: la petición reificada busca su manejador.
• Interpreter + Visitor + Flyweight: sobre el AST de reglas — evaluar/imprimir/optimizar como visitantes, terminales repetidos compartidos.

Nota la constante: las combinaciones no se diseñan "por catálogo" — surgen de que cada patrón resuelve su síntoma y los síntomas conviven en el mismo sistema.

El repaso aplicado, siguiendo el viaje de un pedido:

1. Entra el pedido → la cadena de validación (ManejadorFraude → ManejadorZonaReparto → ManejadorStock → ManejadorImporteMinimo) lo aprueba o rechaza, montada por configuración y disparada por la FachadaCheckout — Chain of Responsibility.
2. Se calcula el envío con la CalculoEnvio del mercado (distancia, plana, gratis por promoción), y las promociones se evalúan con las ExpresionRegla que marketing escribe como texto — Strategy e Interpreter.
3. El cliente edita el carrito con puntos de retorno: Carrito.Memento en el HistorialCarrito — Memento.
4. El pedido vive su ciclo: EstadoPedido autoriza cada transición (CREADO → PAGADO → EN_PREPARACION → EN_REPARTO → ENTREGADO / CANCELADO) — State — y cada transición legal se difunde a NotificadorCliente, NotificadorRepartidor, MonitorCocina y PanelEstadisticas — Observer, saldando la deuda de la lección 01-01.
5. El restaurante gestiona desde su panel con Comandos apilables, deshacibles y encolables — Command.
6. El reparto se coordina en estrella: CentralReparto media entre cocina, pedidos y repartidores, con la EstrategiaAsignacion intercambiable — Mediator + Strategy.
7. La carta se explota: recorrida con Iterable<Plato> (buscador, streams) y operada por VisitanteCarta (exportación, alérgenos, auditoría) — Iterator y Visitor.
8. Cada noche, los informes de cierre siguen el esqueleto de InformeCierre con sus pasos por formato — Template Method.

Para cada síntoma, nombra el patrón (y, si dudaste entre dos, cuál descartaste y por qué):

1. "Cuando el repartidor marca 'entregado', deben reaccionar la app del cliente, la facturación y las métricas — y el mes que viene, el programa de puntos."
2. "El asistente de onboarding de restaurantes tiene 6 pantallas con el mismo flujo (validar → guardar → siguiente) y pasos distintos por pantalla."
3. "Queremos que soporte pueda revertir las últimas 10 acciones hechas sobre un pedido, con auditoría de quién hizo qué."
4. "La tarifa de la comisión se calcula distinto para restaurantes premium, estándar y nuevos, elegida por su contrato."
5. "Un ajuste de precio pasa por: validación automática → aprobación del gestor de zona → aprobación de finanzas si supera el 10%."

Sin mirar las lecciones: escribe las dos "pruebas del algodón" que usarías ante un código dudoso entre (a) State y Strategy, (b) Chain y Decorator. Después aplica (a) a este caso: CalculadoraImpuestos recibe en el constructor un RegimenFiscal que jamás cambia tras construirse y cuyas variantes (RegimenGeneral, RegimenSimplificado) no se conocen entre sí.

El equipo quiere "deshacer" también en la edición de la carta del restaurante: cada operación del editor (renombrar sección, cambiar precio, mover plato) debe poder revertirse, y "reequilibrar precios" (masivo, con redondeos) también. Diseña la solución nombrando los patrones que combinarías y qué papel juega cada uno.

Solución 1:

1. Observer — interesados variables y anónimos ante un cambio. (Descartado Mediator: nadie dirige un protocolo; cada uno reacciona a lo suyo.)
2. Template Method — flujo fijo, pasos variables por pantalla. (Descartado Strategy: no varía el algoritmo entero ni hace falta cambiarlo en caliente.)
3. Command (+ Memento para las acciones sin inversa limpia) — peticiones reificadas con histórico, undo y auditoría.
4. Strategy — algoritmos alternativos elegidos desde fuera (el contrato), sin transiciones entre ellos. (Descartado State: un régimen no "transita" a otro por las operaciones.)
5. Chain of Responsibility — la petición escala por manejadores que la aprueban o la pasan, con eslabones condicionales (finanzas solo a veces). (Descartado Decorator: hay corte y condición, no capas que siempre suman.)

Solución 2: (a) ¿el objeto delegado se sustituye a sí mismo desde dentro, siguiendo un grafo de transiciones? → State; ¿lo elige el exterior y las variantes se ignoran? → Strategy. (b) ¿algún elemento puede legítimamente cortar la cadena? → Chain; ¿todos aportan siempre su capa? → Decorator. El caso: Strategy — lo fija el exterior al construir, sin transiciones ni conocimiento mutuo. (Que "jamás cambie tras construirse" no lo convierte en otra cosa: la intercambiabilidad es entre instancias del contexto, no necesariamente en caliente.)

Solución 3: Command como columna vertebral: cada operación del editor es un Comando con ejecutar()/deshacer(), apilado en un invoker con pila (el patrón del PanelGestion). Las operaciones simples y simétricas (renombrar) deshacen por inversa; "reequilibrar precios" deshace por Memento — su ejecutar() captura antes una instantánea de la carta (copia profunda del Composite, disciplina Prototype) y su deshacer() la restaura. Opcional y coherente: los cambios confirmados se difunden por Observer (la caché ProxyCacheCatalogo y el buscador quieren enterarse). Command da el marco uniforme; Memento entra solo donde la inversa no llega — combinar es asignar a cada patrón su síntoma, no apilarlos por gusto.

Ya distingues a los once por la intención, que es lo único que a veces los separa: sabes qué reifica cada uno, tienes los cinco careos con sus pruebas del algodón, el árbol de decisión para orientarte y las combinaciones que funcionan porque cada pieza ataca su propio síntoma. Y PideYa quedó como demostración viviente: de la cadena que filtra pedidos al visitante que audita la carta, cada patrón del módulo está instalado donde su dolor lo reclamaba.

Los 23 patrones del GoF están ahora en tu caja de herramientas: los creacionales resolvieron el nacimiento de los objetos, los estructurales su anatomía, y los de comportamiento sus conversaciones — quién avisa a quién, dónde viven los algoritmos, cómo se deshace lo hecho. Hasta la deuda más antigua del curso, aquel cambiarEstado de la primera lección, quedó saldada por Observer con State vigilando la puerta.

Pero conocer el catálogo no es saber usarlo — es la diferencia entre tener las herramientas y ser buen carpintero. Las preguntas que vienen ahora son las difíciles: ¿cómo se elige patrón ante un problema real que no llega etiquetado? ¿Cómo se refactoriza código vivo hacia un patrón sin romperlo? ¿Cuándo un patrón bien aplicado se convierte en un antipatrón? ¿Qué patrones usan de verdad Spring, el JDK o el código de tu empresa? Ese es el oficio, y es el módulo entero que empieza: nos vemos en Cómo Seleccionar el Patrón Adecuado.