Ya conoces los cinco patrones creacionales por separado. Esta última lección del módulo los pone sobre la misma mesa, que es donde se toman las decisiones reales: rara vez la pregunta es "¿cómo funciona Builder?" sino "¿qué uso aquí: un builder, una fábrica, o nada?". Compararemos intenciones y costes, te daré una guía de decisión en forma de diagrama, veremos cómo se combinan entre sí (en el código real casi nunca aparecen solos) y cuál es su evolución típica en la vida de un proyecto. Cerraremos con el mapa creacional completo de PideYa: qué patrón quedó instalado en cada parte del sistema y por qué.

1. Los cinco, frente a frente
2. Guía de decisión
3. Cómo se combinan entre sí
4. La evolución típica: los patrones se ganan
5. El mapa creacional de PideYa
6. Errores comunes, ejercicios y conclusión

La tabla que conviene tener interiorizada (las columnas de coste retoman la balanza de la lección 01-06):

Dos ejes transversales que ayudan a no confundirlos:

• ¿Dónde está la dificultad? En elegir la clase → fábricas (una pieza: Factory Method; familia coherente: Abstract Factory). En montar el objeto → Builder. En el punto de partida (ya existe uno igual) → Prototype. En cuántas instancias → Singleton.
• ¿Qué se le da al mecanismo? A una fábrica se le dan parámetros y decide la clase; a un builder se le dan datos poco a poco y monta; a un prototipo no se le da nada: ya contiene su estado.

El flujo de preguntas que resume el módulo. Como toda guía, orienta el 90% de los casos; el 10% restante es criterio (y recuerda el filtro previo a todos: ¿de verdad duele el new directo?):

Tres consejos de uso de la guía:

• Las respuestas pueden ser varias a la vez: un pedido complejo (Builder) cuya pasarela de cobro elige una fábrica de mercado (Abstract Factory) es lo normal, no la excepción. La guía se aplica por decisión de creación, no por sistema.
• Cuando dudes entre Factory Method y Abstract Factory, la pregunta discriminante es siempre la misma: ¿hay invariante de coherencia entre varios productos? Sin familia, no hay Abstract Factory.
• Cuando dudes entre Builder y fábrica: la fábrica esconde qué clase; el builder esconde qué pasos. Si el cliente conoce perfectamente la clase (Pedido) pero sufre montándola, es Builder.

Los creacionales son piezas de Lego, y en el código real aparecen ensamblados. Las combinaciones canónicas, todas presentes o plausibles en PideYa:

• Abstract Factory implementada con Factory Methods. Cada método crearX() de FabricaEspana es un factory method: la fábrica abstracta es, estructuralmente, un paquete de factory methods agrupados por variante. Lo viste en la lección 02-04.
• Fábricas expuestas como Singleton (o mejor, inyectadas como instancia única). FabricaMexico no tiene estado propio: no hay motivo para instanciarla más de una vez. Lo habitual: instancia única creada en la raíz de composición e inyectada; el Singleton clásico queda para el caso sin contenedor.
• Builder dentro de una fábrica. Una fábrica cuyo producto es complejo lo monta internamente con su builder: FabricaEspana.crearFormateadorTicket() puede devolver FormateadorTicket.builder().normativa(ES).moneda(EUR).build(). El cliente ve fábrica; la fábrica usa builder. Cada patrón resuelve su capa.
• Fábrica que devuelve el builder. Pedido.builder(cliente, restaurante) —nuestro punto de entrada de la lección 02-05— es un método estático de fabricación... que fabrica un builder. La combinación es tan natural que ni se nota.
• Abstract Factory implementada con Prototype. En vez de una clase de fábrica por mercado, un juego de ejemplares prototípicos por mercado que la fábrica clona. Útil cuando las variantes se definen por configuración (datos) más que por código.
• Registro (de Suppliers o de prototipos) como columna vertebral. El registro de la lección 02-03 y el de plantillas de la lección 02-06 son el mismo esqueleto con relleno distinto: recetas en uno, ejemplares en otro. Ambos convierten "añadir una variante" en "registrar una entrada", sin tocar el núcleo.

La secuencia que viste en las lecciones no es casual: es la trayectoria natural de un punto de creación durante la vida de un proyecto sano. Conviene tenerla explícita, porque te dice cuándo parar:

Cada flecha tiene un peaje de entrada: el síntoma que la justifica. Recorrerla entera "por si acaso" el primer día es la sobreingeniería de la lección 01-06; quedarse en new directo cuando ya hay tres switch duplicados es el error simétrico. PideYa recorrió la secuencia completa solo en pagos e impuestos (donde la internacionalización la exigió); las notificaciones se quedaron en el registro de Suppliers; y decenas de objetos pequeños siguen felizmente en new directo. Las tres paradas son correctas: cada una es la respuesta proporcionada a su nivel de dolor. Builder y Prototype orbitan aparte de esta secuencia: no evolucionan desde la fábrica sino desde el objeto (constructor que engorda → Builder; reconstrucción repetitiva → Prototype). Y el camino inverso también existe: si las variantes de una Abstract Factory se reducen a una y nada apunta a que vuelvan, degradarla a fábrica simple es refactorizar bien, no rendirse (más sobre esto en Refactorización Usando Patrones).

Cerremos el módulo como empezó: mirando el sistema entero. Esto es lo que quedó instalado, lección a lección, con su justificación en una línea:

Fíjate en la última fila: es tan importante como las demás. Un diseño maduro no es el que más patrones tiene, sino el que tiene cada patrón donde su síntoma lo justificó — la vara de medir que fijamos en la lección de la balanza.

• Elegir por familiaridad, no por problema. "Uso Factory Method porque es el que mejor conozco" produce fábricas donde hacía falta un builder. La guía de decisión existe para forzar las preguntas correctas antes que las respuestas cómodas.
• Confundir la pareja estrella. Factory Method y Abstract Factory seguirán confundiéndose en entrevistas y revisiones; recita el discriminante: un método que crea un producto frente a un objeto que crea una familia coherente.
• Saltarse peldaños de la evolución. Montar la Abstract Factory de mercados cuando PideYa solo operaba en España habría sido flexibilidad especulativa pura. El peaje de cada flecha se paga cuando el síntoma llega, no antes.
• No desmontar patrones que ya no pagan. La evolución también va hacia atrás: mantener una jerarquía de fábricas para una única variante desde hace dos años es deuda estructural con disfraz de diseño.
• Tratar las combinaciones como excepciones. Un builder dentro de una fábrica, o una fábrica que devuelve builders, no es "mezclar patrones": es lo normal. Cada patrón gobierna una capa de la decisión de creación.
• Consejo: en tu próximo proyecto, haz el ejercicio del mapa: una tabla como la de PideYa con cada punto de creación relevante, su solución y su justificación en una línea. Si alguna fila no puede justificarse con un síntoma, tienes un candidato a simplificar.

Para cada situación nueva en PideYa, elige el patrón creacional (o la ausencia de patrón) y justifica en una frase con el discriminante adecuado:

1. El módulo de informes debe generar un objeto PanelEstadisticas con 12 widgets configurables, umbrales opcionales y validación de rangos.
2. Marketing quiere campañas de email cuyo contenido se define visualmente en un panel de administración; cada campaña nueva parte de una existente "que funcionó".
3. Al integrar recogida en tienda para supermercados, cada cadena (Mercadona, Carrefour) exige su API de stock, su formato de código de barras y su pasarela de fidelización, siempre a juego.
4. Un desarrollador propone hacer singleton el CarritoActual "para acceder a él desde cualquier pantalla de la app".
5. Hay que crear el objeto ExportadorDatos adecuado (CSV, JSON o Parquet) según un parámetro; hoy hay tres formatos y no se prevén familias ni coherencias.

Describe qué patrones creacionales colaboran en este fragmento y qué papel cumple cada uno:

El generador de códigos promocionales de PideYa nació como new GeneradorCodigos() en un único servicio. Hoy: (a) marketing pide códigos alfanuméricos para campañas normales y códigos QR para campañas de cartelería; (b) el switch que los distingue ya está copiado en dos servicios. Describe la evolución paso a paso que aplica la secuencia de la sección 4, indicando en qué parada te detendrías hoy y qué síntoma futuro te haría avanzar a la siguiente.

Solución 1:

1. Builder: la clase es conocida y el problema es el montaje (opcionales + validación cruzada).
2. Prototype con registro: los ejemplares se definen con datos en ejecución y el punto de partida natural es una campaña existente; ninguna solución basada en clases nuevas encaja con un panel de administración.
3. Abstract Factory: tres piezas por cadena con invariante de coherencia ("siempre a juego"): familia de manual.
4. Ningún patrón, y además rechazo razonado: el carrito es estado de negocio mutable y por usuario; un singleton lo compartiría entre sesiones (bug grave) y ocultaría la dependencia. Corresponde a la sesión/contexto, inyectado.
5. Simple factory (o registro de Supplier si se prevén más formatos): un producto, sin familias; con tres casos estables, el idiom basta y el patrón completo sería ceremonia.

Solución 2: colaboran Abstract Factory (la clase FabricaMexico, que garantiza la familia coherente del mercado mexicano), Factory Method (el método crearFormateadorTicket() es uno de sus factory methods: decide el producto concreto de esta variante) y Builder (FormateadorTicket.builder()...build() monta el producto complejo paso a paso, con la validación que corresponda en build()). Tres capas de la misma decisión: qué familia → qué producto → cómo se monta.

Solución 3: evolución razonable: (1) el new directo dejó de bastar cuando apareció la segunda clase concreta (alfanumérico/QR) y el switch se duplicó: síntomas claros → extraer una simple factory (FabricaGeneradoresCodigo.crear(tipo)) que deduplica y centraliza. (2) Parada actual: ahí me detendría hoy — dos variantes estables y un solo punto de decisión no justifican más. (3) Síntoma que haría avanzar a Factory Method/registro de Suppliers: nuevas variantes con cadencia real (códigos por partner, por app externa) o la necesidad de que otros módulos registren generadores sin tocar el núcleo. (4) Abstract Factory solo entraría si algún día cada campaña exigiera varias piezas coherentes (generador + validador + render, a juego por tipo de campaña); hoy no existe esa familia, así que anticiparla sería especulación.

El módulo empezó con una pregunta —¿quién decide qué clase concreta se instancia, y dónde?— y ahora tienes cinco respuestas con sus discriminantes: Singleton para la unicidad (mejor, inyección), Factory Method para variar el producto, Abstract Factory para blindar familias, Builder para domar el montaje, Prototype para partir de un ejemplar. Sabes que se combinan por capas, que se llega a ellos por una evolución guiada por síntomas —y que se abandona igual—, y tienes el mapa de PideYa como plantilla del resultado final: cada patrón donde su dolor lo justificó, y new directo donde no había dolor.

Con el nacimiento de los objetos resuelto, la siguiente pregunta es inevitable: una vez creadas las piezas —pasarelas, notificadores, pedidos—, ¿cómo se conectan y organizan entre sí sin que el conjunto se vuelva una maraña? Esa es la segunda familia del catálogo: adaptar interfaces que no encajan, componer estructuras en árbol, envolver objetos con responsabilidades extra, simplificar subsistemas enteros tras una fachada. Nos vemos en la Introducción a los Patrones Estructurales.