El módulo anterior terminó con el nacimiento de los objetos resuelto: fábricas, builders y prototipos deciden qué se instancia, cómo se monta y de dónde se parte. Pero un sistema no es una colección de objetos bien nacidos: es una red de objetos conectados. Y en PideYa esa red ya empieza a tensarse: un SDK de pagos externo cuya interfaz no encaja con nuestra PasarelaPago, una carta de restaurante que es un árbol de secciones dentro de secciones, extras de platos que multiplican subclases, un checkout que obliga a cada pantalla a conocer cinco subsistemas... Ninguno de estos problemas va de crear objetos: van de componerlos. Esa es la segunda familia del catálogo GoF, y esta lección es su mapa.

1. El problema común: componer sin acoplar
2. Panorama de los siete patrones estructurales
3. Ámbito de clase y ámbito de objeto
4. Síntomas en PideYa de que hace falta un estructural
5. Cómo leeremos cada patrón en este módulo
6. Ejercicios y conclusión

Los patrones creacionales respondían a una pregunta: ¿quién decide qué clase concreta se instancia? Los estructurales responden a otra: ¿cómo se ensamblan clases y objetos en estructuras mayores sin que la estructura se vuelva rígida?

La palabra clave es estructura: relaciones entre piezas. Y el enemigo es el mismo de siempre, con otra cara: el acoplamiento. En el módulo 2 el acoplamiento se colaba por el new; aquí se cuela por las conexiones:

• Una clase que depende de la interfaz exacta de otra que no controlamos (una API de terceros): cuando el tercero cambia, o cuando queremos cambiar de tercero, todo se rompe.
• Una jerarquía de herencia que crece multiplicativamente: cada dimensión de variación nueva duplica las subclases.
• Un cliente que para hacer una operación debe conocer y coordinar media docena de objetos: el conocimiento de la estructura interna se esparce por todo el sistema.
• Estructuras recursivas (árboles parte-todo) tratadas con if (esGrupo) ... else ... por todas partes.
• Objetos caros (memoria, red, carga) creados y conectados sin control, porque nadie media en el acceso.

Los siete patrones estructurales son siete maneras de organizar las conexiones para que sigan cumpliendo lo que aprendimos en la lección de principios: programar contra interfaces, preferir composición sobre herencia, y poder extender sin modificar. De hecho, verás que casi todos los estructurales son aplicaciones sistemáticas de "composición sobre herencia": un objeto que envuelve, contiene o remite a otros, en lugar de una jerarquía que lo hereda todo.

La foto completa del módulo, cada patrón en una línea. No intentes memorizarla ahora: volveremos a ella, ampliada, en la comparativa final.

Una observación que conviene hacer ya, porque evita la mayor confusión del módulo: cuatro de los siete (Adapter, Decorator, Facade y Proxy) comparten mecánica —un objeto delante de otro, delegando— y se distinguen solo por la intención. Adapter cambia la interfaz; Decorator la conserva y añade responsabilidades; Facade la simplifica; Proxy la conserva y controla el acceso. Recuerda la definición de patrón de la primera lección: contexto, problema, solución e intención. En esta familia, la intención es a menudo lo único que separa un patrón de otro; les dedicaremos un careo completo en la comparativa.

Los otros tres organizan multitudes: Composite organiza objetos en árboles, Bridge organiza jerarquías en dos ejes independientes, y Flyweight organiza miles de instancias compartiendo lo común.

En la clasificación GoF vimos que cada patrón tiene un ámbito: de clase si la relación se fija con herencia en tiempo de compilación, o de objeto si se establece con composición en tiempo de ejecución.

En la familia estructural la cuenta es rotunda: seis de los siete son de ámbito de objeto. Solo Adapter existe en las dos variantes, y por eso es el ejemplo perfecto para entender la diferencia:

• Adapter de clase: el adaptador hereda de la clase que adapta y a la vez implementa la interfaz esperada. La relación queda soldada al compilar: ese adaptador sirve para esa clase concreta y sus subclases no.
• Adapter de objeto: el adaptador contiene una referencia al objeto adaptado y delega en él. La relación se decide al construir: el mismo adaptador puede envolver cualquier objeto compatible, incluso decidido en ejecución.

Que casi toda la familia sea de ámbito de objeto no es casualidad: es el principio de composición sobre herencia hecho catálogo. La herencia fija la estructura para siempre; la composición permite reconfigurarla —envolver, desenvolver, recombinar— mientras el programa corre. Verás esta idea repetida en cada lección: el decorador se apila en ejecución, el árbol del composite se monta en ejecución, el puente se cruza en ejecución.

Igual que el módulo 2 empezó catalogando los dolores del new, este empieza catalogando los dolores de la composición. Todos son reales en PideYa hoy; cada uno tiene su lección:

Fíjate en el criterio, que es el mismo de todo el curso: primero el síntoma, después el patrón. Ninguna de las lecciones siguientes empieza por "apliquemos X"; todas empiezan por un dolor concreto de PideYa y llegan al patrón como respuesta proporcionada. Si en tu proyecto no reconoces el síntoma, la lección de la balanza ya te dijo qué hacer: nada.

Las siete lecciones de patrón siguen el mismo esqueleto que las del módulo 2, para que puedas compararlos entre sí sin esfuerzo:

1. El problema en PideYa: el síntoma de la tabla anterior, con código del primer intento (el malo).
2. Estructura del patrón: intención GoF y classDiagram mermaid con los roles del patrón, como aprendimos en la lección de UML.
3. Implementación Java completa, explicada paso a paso.
4. Variantes relevantes (de clase/objeto, transparente/segura, estática/dinámica según el patrón).
5. Cuándo usarlo y cuándo no, con la honestidad de costes habitual.
6. Relación con otros patrones: solo menciones con enlace; cada cosa se desarrolla en su lección.
7. Errores comunes, ejercicios con solución y conclusión que enlaza con la lección siguiente.

Y seguimos construyendo sobre lo construido: la PasarelaPago y la familia por mercado del módulo 2 reaparecerán en Adapter y Facade; los Notificador del Factory Method serán decorados y puenteados; el Pedido.Builder participará en el checkout de la fachada. Los patrones no viven en lecciones estancas: viven en el mismo sistema.

Para cada situación nueva de PideYa, di qué patrón estructural de la tabla parece apuntar (no hace falta que sepas aún cómo funciona; basta con casar síntoma e intención de una línea):

1. El equipo de datos quiere consultar pedidos con una librería de informes cuya interfaz de lectura no coincide con nuestro repositorio de pedidos.
2. Un "menú del día" contiene primero, segundo y postre; y un "menú familiar" contiene dos menús del día y una bebida grande. Queremos calcular el precio de cualquier cosa que se pueda pedir, sea plato suelto o menú anidado.
3. Queremos que ciertas llamadas al servicio de reparto queden registradas en RegistroEventos y se reintenten si fallan, sin tocar la clase del servicio.
4. La pantalla "estado de mi pedido" necesita datos de cocina, de reparto y de pagos; hoy la app llama a los tres servicios y combina los resultados a mano.

Explica con tus palabras por qué un Adapter de objeto puede adaptar en ejecución "cualquier pasarela vieja que nos llegue" y un Adapter de clase no. ¿Qué relación UML de la lección 01-04 usa cada uno?

Solución 1:

1. Adapter: dos interfaces que no encajan y una de ellas (la librería) no es nuestra.
2. Composite: estructura parte-todo recursiva (menús que contienen menús) con una operación uniforme (precio).
3. Decorator (con matiz de Proxy que afinaremos en sus lecciones): añadir responsabilidades —logging, reintentos— envolviendo, sin modificar la clase.
4. Facade: un punto único y simple que orquesta varios subsistemas para un caso de uso.

Solución 2: el Adapter de objeto contiene (composición/agregación, la relación o--) una referencia tipada a lo adaptado, que se le pasa al construir: en ejecución puede recibir una instancia u otra, incluso de subclases distintas. El Adapter de clase hereda (generalización, <|--) de una clase concreta: la relación queda fijada al compilar y solo vale para esa clase. Es exactamente la diferencia entre ámbito de objeto y ámbito de clase, y la razón de que "composición sobre herencia" sea el lema de esta familia.

Ya tienes el mapa del módulo: siete patrones que resuelven un mismo problema de fondo —componer clases y objetos en estructuras mayores manteniéndolas flexibles— atacándolo por siete frentes: interfaces que no encajan, jerarquías que se multiplican, árboles parte-todo, responsabilidades añadidas, subsistemas complejos, multitudes de objetos y accesos que controlar. Sabes que casi todos son de ámbito de objeto (composición sobre herencia llevado a catálogo), y que cuatro de ellos comparten mecánica y se distinguen por la intención, así que la intención será nuestra brújula.

Empezamos por el más inmediato de todos, el que aparece siempre que el mundo exterior llama a nuestra puerta con una interfaz que no es la nuestra: PideYa necesita cobrar con un SDK heredado que no habla PasarelaPago, y no podemos tocar ni el SDK ni todo el código que ya usa PasarelaPago. La pieza no encaja... salvo que le construyamos un enchufe. Nos vemos en Adapter.