En los módulos 2 a 4 cada patrón tuvo su lección y su rincón de PideYa; en la lección anterior aprendiste el método para elegirlos. Esta lección junta ambas cosas y las lleva a la escala real: funcionalidades completas donde varios patrones colaboran, y donde lo interesante ya no es cada pieza sino las costuras — el punto exacto donde un patrón termina y otro empieza, y por qué la frontera está ahí y no en otro sitio. Veremos dos casos: el flujo completo de un pedido (seis patrones ya construidos, vistos por fin de una sola pasada) y un módulo nuevo de fidelización construido desde cero aplicando el método — incluidas las decisiones de no usar patrón, que en código real son la mitad del diseño.

1. Caso A: el viaje completo de un pedido — seis patrones, cinco costuras
2. Las costuras, una a una
3. Caso B: el módulo de fidelización, diseñado desde cero con el método
4. Los trade-offs: dónde decidimos no usar patrón
5. Ejercicios y conclusión

Cada patrón de esta secuencia tiene su lección; lo que nunca habíamos dibujado es el conjunto. Un cliente pulsa "confirmar pedido" y esto es lo que ocurre:

En texto, la cadena de responsabilidades (con minúscula) es esta:

1. Facade — FachadaCheckout es el único punto de entrada: la app no conoce ni la cadena, ni las estrategias, ni el builder. Su papel: orquestar y ocultar.
2. Chain of Responsibility — la fachada dispara la validación (ManejadorFraude → ManejadorZonaReparto → ManejadorStock → ManejadorImporteMinimo). Su papel: decidir si el pedido entra, sin que la fachada sepa cuántos filtros hay.
3. Strategy — CalculoEnvio calcula los gastos con la variante del mercado. Su papel: un cálculo intercambiable sin if en la fachada.
4. Builder — Pedido.Builder monta el objeto con sus líneas, envío e impuestos, validando invariantes en build(). Su papel: construcción compleja fuera del constructor.
5. State — el pedido nace en CREADO y pagar() transita a PAGADO solo si el estado lo autoriza. Su papel: que cada operación sea legal solo cuando toca.
6. Observer — transitarA difunde la transición a cliente, cocina y estadísticas. Su papel: que los interesados se enteren sin que el pedido los conozca. La máxima del módulo 4 sigue vigente: State autoriza, Observer difunde.

Lo que hace que esto sea un diseño y no un montón de patrones es dónde está cada frontera:

Costura fachada–cadena. La fachada conoce un objeto: el primer eslabón (inyectado ya montado, como se configuró en 04-02). Si mañana compliance exige un quinto filtro, se añade al montaje de la cadena y la fachada no cambia. La costura es la interfaz ManejadorPedido: por encima de ella, orquestación; por debajo, política de admisión.

Fíjate en lo que la fachada no hace: no valida (cadena), no calcula (estrategia), no construye (builder), no cambia estados a mano (State) y no notifica a nadie (Observer). Diez líneas de orquestación pura — cada responsabilidad expulsada hacia el patrón cuyo síntoma la reclamaba. Esa es la prueba de que las costuras están bien puestas: la fachada sigue siendo aburrida.

Costura State–Observer — la más fina del sistema y la más fácil de romper. Un solo punto las conecta:

Si un observador empezara a provocar transiciones (cocina que al enterarse de PAGADO llama a prepararse() sobre el mismo pedido en el mismo hilo), la difusión se volvería recursiva y el orden de notificación pasaría a ser lógica de negocio encubierta — la señal de que esa reacción pertenece a un Mediator o a un comando explícito, no al observador.

Negocio pide: "programa de puntos: cada pedido entregado acumula puntos según reglas por nivel (bronce/plata/oro); los puntos se canjean por cupones; los cupones se aplican en el checkout". No hay código previo. Apliquemos el método de 05-01 decisión a decisión:

El corazón del módulo, con las piezas elegidas:

La decisión más valiosa de la tabla es la primera: reutilizar el Observer existente en vez de inventar infraestructura. Un módulo nuevo bien diseñado se acopla a las costuras que el sistema ya ofrece — por eso las costuras importan más que los patrones.

Tres tentaciones descartadas, con su porqué — porque el diseño real se cuenta también por lo que no se construyó:

• ¿Chain of Responsibility para aplicar los cupones en orden? Tentador: "cada cupón decide si aplica y pasa al siguiente"... pero todos los cupones aplicables deben aplicarse, nadie corta la cadena. Falla la prueba del algodón de 04-13. Un for sobre una List<ReglaDescuento> ordenada hace lo mismo con cero clases extra:

• ¿Interpreter para las reglas de canje? ("500 puntos Y nivel >= plata"). Ya existe ExpresionRegla de 04-04 para promociones... pero las reglas de canje hoy son dos y las escribe el propio equipo en Java, no marketing en texto. Sin autor externo del mini-lenguaje, Interpreter es coste sin cliente. Nota de intención en el código y a otra cosa.
• ¿Facade propia para fidelización? El módulo tiene tres operaciones públicas (consultarPuntos, canjear, aplicarCupones) sobre dos clases. Una fachada delante de tan poco es una puerta monumental para un trastero — se reevaluará si el módulo crece.

El saldo final del módulo: dos Strategy, un Observer reutilizado, un Factory Method con registro — y tres patrones descartados con argumento. Eso es aplicar el catálogo con criterio: cada patrón presente tiene un síntoma que lo reclama, y cada ausencia tiene un porqué articulado.

• Diseñar el módulo "por patrones" ("necesitará su Singleton, su Factory y su Facade") en vez de por decisiones. La tabla decisión-a-decisión del caso B es el antídoto: cada fila tiene fuerzas y diagnóstico, no cuota de patrones.
• Duplicar infraestructura en vez de enchufarse a las costuras existentes. Antes de crear tu propio sistema de eventos, cadena o fábrica, mira si el sistema ya expone uno (el AcumuladorPuntos no inventó nada: se suscribió).
• Costuras gordas: si la fachada empieza a validar "solo este caso especial" o un observador empieza a orquestar, la frontera se está deshaciendo. La fachada debe seguir siendo aburrida; el observador, reactivo.
• No registrar los descartes. El próximo desarrollador verá el for de cupones y pensará "aquí falta un Chain". Un comentario de dos líneas con el porqué del descarte vale más que la elegancia silenciosa.
• Consejo: en revisión de diseño, pide siempre las dos listas — patrones usados y patrones descartados. Un diseño sin descartes casi nunca ha sido diseñado: ha sido decorado.

Sin mirar el diagrama: dibuja (o describe) el viaje del pedido del caso A nombrando los seis patrones y las cinco costuras (qué interfaz o punto de código separa cada par). Después responde: si negocio pide "los pedidos de más de 100 € requieren verificación telefónica antes de cocinarse", ¿qué costura absorbe el cambio y qué patrones no se enteran?

Negocio amplía: "en el cumpleaños del cliente, sus pedidos acumulan puntos dobles, se combinen como se combinen con su nivel". Aplica el método: fuerzas, diagnóstico, candidato — y cuidado: hay una solución con patrón estructural del módulo 3 y una solución sin patrón; presenta ambas y elige según los filtros.

Un compañero implementó la aplicación de cupones como Chain of Responsibility real: cada cupón hereda de ManejadorCupon, aplica su descuento y llama a siguiente.manejar(...). Funciona. Escribe (a) por qué formalmente no es un Chain aunque lo parezca, (b) qué problema práctico causará el día que un cupón deba "cortar" de verdad (cupón exclusivo no combinable), (c) la refactorización mínima hacia la versión con lista.

Solución 1: Costuras: (1) app–fachada: el método confirmarPedido (la app no ve nada más); (2) fachada–cadena: la interfaz ManejadorPedido del primer eslabón; (3) fachada–estrategia: la interfaz CalculoEnvio; (4) fachada–builder: la API fluida de Pedido.Builder; (5) pedido–observadores: transitarA. El cambio de la verificación telefónica es una regla de admisión condicional que puede cortar → nuevo eslabón ManejadorVerificacionTelefonica en el montaje de la cadena (costura 2)... o, si la verificación es asíncrona (esperar la llamada), un estado nuevo EN_VERIFICACION en el ciclo de vida (costura 5, State). Con la lectura síncrona: Builder, Strategy, State y Observer no se enteran; la fachada tampoco — solo cambia el montaje de la cadena.

Solución 2: Fuerzas: varía un multiplicador temporal que se suma sobre el cálculo del nivel; estable la interfaz CalculoPuntos y el acumulador. Opción con patrón: Decorator — CalculoPuntosCumpleanos implements CalculoPuntos que envuelve al cálculo del nivel y duplica su resultado; combina con cualquier nivel sin tocarlo (exactamente los extras de 03-05). Opción sin patrón: un if (cliente.esSuCumpleanos()) puntos *= 2; en el acumulador. Filtros: si el "puntos dobles" es el único modificador previsto, el if gana (KISS); si marketing ya habla de "puntos dobles los martes" y "x3 en tu primera semana premium" — modificadores que se apilan — el eje de variación es real y Decorator paga su coste. La respuesta honesta depende del roadmap, y decirlo así es la respuesta correcta.

Solución 3: (a) La prueba del algodón: en un Chain cada eslabón decide atender o pasar y puede cortar; aquí todos aplican siempre y nadie corta — es una delegación incondicional, o sea la estructura de Decorator con nombre de Chain, y la intención real es "aplicar todos" (un recorrido). (b) Cuando llegue el cupón exclusivo, cortar la cadena hará que el resultado dependa del orden de montaje de forma invisible (¿corta antes o después del cupón de envío gratis?), y el bug será de configuración, indetectable en el código de los cupones. Con lista explícita, la exclusividad es una regla visible (filtrar antes de iterar). (c) Extraer de cada ManejadorCupon su lógica a ReglaDescuento.aplicar(total, carrito), eliminar el campo siguiente, y sustituir el arranque de la cadena por el for sobre la lista ordenada — paso a paso y con tests, como manda la lección de refactorización.

Has visto el catálogo funcionando a escala real: seis patrones colaborando en el viaje de un pedido con la fachada como director de una orquesta que no toca ningún instrumento, y un módulo nuevo diseñado decisión a decisión — con sus patrones elegidos por síntoma, su infraestructura reutilizada por las costuras y sus tres descartes argumentados. La lección de fondo: un buen diseño se reconoce tanto por dónde están las fronteras como por qué patrones lo habitan. Pero PideYa es nuestro laboratorio; la pregunta natural es si el software que usas cada día — el JDK, Spring, Hibernate — está construido igual. Lo está, y aprender a reconocer sus patrones al leer su código es la siguiente lección: Patrones de Diseño en Proyectos Reales.