Cada noche, PideYa genera el informe de cierre diario de cada restaurante: se cargan los pedidos del día, se agregan las cifras, se formatea el resultado y se distribuye. El flujo es siempre el mismo; lo que cambia son pasos concretos: el informe PDF para el dueño formatea y distribuye distinto que el CSV para contabilidad o que el resumen que se envía por email. Strategy nos enseñó a intercambiar algoritmos completos; aquí el algoritmo completo es común y solo varían piezas. Para esto, el GoF reserva su patrón de herencia por excelencia: el esqueleto del algoritmo vive en una clase base, fijado e intocable, y las subclases rellenan los huecos — bajo el principio de Hollywood: "no nos llames; nosotros te llamaremos".

1. El problema en PideYa: informes que se copian el flujo
2. Intención y estructura del patrón
3. Implementación Java completa
4. Hooks: los pasos opcionales
5. El principio de Hollywood
6. Ya has visto este patrón (aunque no lo llamamos)
7. Template Method vs. Strategy: herencia contra composición
8. Cuándo usarlo y cuándo no
9. Relación con otros patrones
10. Errores comunes
11. Ejercicios y conclusión

Hoy existen InformePdfCierre e InformeCsvCierre, y son gemelos con copia-y-pega:

El síntoma exacto: dos algoritmos idénticos en estructura que solo difieren en pasos concretos. Las consecuencias del copia-y-pega ya las conoces: cuando operaciones pide "excluir también los pedidos de prueba", hay que acordarse de tocar todas las copias del filtrado (y la tercera copia, el informe por email que viene en camino, nace ya desincronizada). El flujo común no tiene dueño: vive duplicado en cada variante.

La inversión que lo arregla: el flujo común sube a una clase base como método único e intocable, y los pasos variables bajan a las subclases como métodos abstractos. La base llama a las subclases — no al revés.

Intención (GoF): definir el esqueleto de un algoritmo en una operación, delegando algunos pasos a las subclases. Template Method permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Este es uno de los dos patrones de comportamiento de ámbito de clase (lo anunciamos en la introducción del módulo): la relación se fija con herencia, en compilación.

Los métodos de la base se clasifican en cuatro tipos, y distinguirlos es media lección:

Las subclases quedan reducidas a su diferencia esencial:

Detalles de oficio en la base, todos deliberados:

• generar es final: el esqueleto es el contrato; si una subclase pudiera redefinirlo, el patrón se evapora (y vuelve el copia-y-pega, ahora con herencia).
• Los pasos son protected: son la interfaz hacia las subclases, no hacia el mundo. Nadie de fuera llama a formatear.
• La corrección del filtrado ahora es un solo cambio: "excluir pedidos de prueba" se toca en cargarPedidos y las tres variantes lo heredan al instante.

El hook debeGenerarse merece su sección porque es la herramienta de flexibilidad fina del patrón: un método con implementación por defecto (a menudo vacía o trivial) que las subclases pueden sobrescribir para engancharse al flujo sin estar obligadas. El informe-resumen por email lo usa: si el restaurante no abrió, no hay nada que mandar:

Reglas prácticas para diseñar hooks: pocos y con nombre que delate el momento (debeGenerarse, alTerminarDistribucion); por defecto inofensivos (devolver lo permisivo, no hacer nada); y documentados en la base — son el contrato de extensión. Los frameworks los usan por doquier: los onCreate/onPause de Android o los callbacks de ciclo de vida de Spring son hooks de plantillas gigantes.

"Don't call us, we'll call you." La inversión de control que define al patrón: el código de bajo nivel (las subclases) no llama al flujo; es el flujo (la base) quien llama a las subclases cuando les toca. Compáralo con una librería clásica: tú llamas a Math.max(...) cuando quieres; en Template Method, InformeCsvCierre nunca decide cuándo formatear — es llamado por generar en el momento justo.

Esta inversión es la semilla de algo que ya usas: los frameworks funcionan así. Spring, JUnit o Android definen el flujo (el método plantilla, a escala industrial) y tu código rellena huecos que el framework invoca. La diferencia entre usar una librería y usar un framework es el principio de Hollywood — y lo aprendiste aquí, en un patrón de una clase y media.

Dos reencuentros del propio curso:

• El manejar(...) del Chain of Responsibility: método público que fija el protocolo (comprobar → cortar o delegar) llamando al comprobar abstracto de cada eslabón. Lo llamamos entonces "truco de plantilla"; era exactamente este patrón en miniatura.
• El flujo común de las Notificacion del Bridge admite la misma jugada: un enviar() final en la abstracción que hace validar → componer → enviar por el canal, con componer() abstracto por tipo de notificación. Template Method dentro del lado izquierdo de un Bridge: los patrones anidan.

Y en el JDK: AbstractList te da add, contains o indexOf gratis si implementas get y size (plantillas sobre primitivas), y los tests con @BeforeEach/@Test/@AfterEach de JUnit son un método plantilla que tú no ves y que llama a tus métodos.

El careo prometido en la lección anterior — mismo problema (variar el "cómo" sin tocar a los clientes), soluciones en las dos escuelas:

La guía de decisión, honesta: si los pasos variables necesitan compartir mucho contexto del flujo y las variantes son pocas y estables, Template Method es directo y conciso. Si necesitas cambiar la variante en ejecución, combinar ejes de variación o testear las variantes aisladas del flujo, Strategy — de hecho, la evolución típica es empezar con Template Method y, cuando las subclases se multiplican por combinatoria, extraer cada paso variable como estrategia inyectada ("composición sobre herencia" tiene su historia desde el módulo 1, y esta es su batalla clásica). Ambos conviven bien: un método plantilla cuyos pasos delegan en estrategias.

Úsalo cuando:

• Varias clases implementan el mismo algoritmo con pasos distintos y el copia-y-pega ya duele (o va a doler: tercera variante a la vista).
• Quieres fijar el orden del flujo como contrato inviolable y ofrecer puntos de extensión controlados (pasos y hooks).
• Estás construyendo una base reutilizable o mini-framework interno donde otros equipos rellenan huecos.

Evítalo cuando:

• Las variantes necesitan cambiar en ejecución o combinarse: la herencia lo fija todo al construir — Strategy.
• La "parte común" es pequeña o forzada: una base artificial para compartir dos líneas acopla jerarquías enteras por nada; a veces un método estático compartido es la respuesta aburrida y correcta.
• Ya hay una jerarquía por otro motivo: la herencia es un recurso único en Java; gastarla en el flujo de informes impide usarla para otra cosa.

• Strategy: la tabla de arriba; pasos de plantilla extraíbles como estrategias.
• Factory Method: GoF lo define literalmente como "una especialización de Template Method" donde el paso variable es crear un objeto — nuestro viejo conocido del módulo 2, reencuadrado.
• Chain of Responsibility y Bridge: los reencuentros de la sección anterior.
• Builder: el director de un builder ejecuta pasos de construcción en orden fijo — espíritu de plantilla en el mundo creacional.

• Método plantilla no-final: una subclase lo redefine "solo para este caso" y el esqueleto único se fragmenta. final no es paranoia; es el patrón.
• Demasiados pasos abstractos: si la base delega todo, no hay plantilla — solo una interfaz cara. La base debe poseer el flujo y la mayor parte del trabajo común.
• Hooks que las subclases están obligadas a llamar (super.alTerminar() "o se rompe todo"): el contrato frágil clásico de la herencia. Diseña la base para que lo obligatorio viva en la plantilla, no en la buena memoria del que hereda.
• Subclases que se saltan el flujo llamando a los pasos directamente (formatear desde fuera de generar): visibilidad protected y disciplina; los pasos no son API pública.
• Estado mutable protected compartido a manos llenas: las subclases acaban dependiendo de las tripas de la base y cada refactor de la base rompe hijos. Pasa datos como parámetros de los pasos (como nuestro CifrasCierre) siempre que puedas.

Implementa InformeJsonCierre: formatea las cifras como JSON (usa el formato que quieras) y las publica en almacenDatalake.publicar("cierres/" + dia + "/" + restauranteId + ".json", contenido). ¿Cuántas líneas de flujo (cargar/filtrar/agregar) has escrito?

Operaciones quiere que, tras distribuir con éxito, cada informe pueda opcionalmente registrar métricas (el PDF no; el CSV debe anotar metricas.registrarEnvioContabilidad(dia)). Añade el hook a la base (nombre, firma, implementación por defecto, punto de llamada en generar) y úsalo en InformeCsvCierre.

El equipo de notificaciones quiere unificar el flujo validar destinatario → componer mensaje → enviar → registrar: (a) si las variantes son "confirmación", "retraso" y "promoción", que difieren solo en componer, ¿qué usarías?; (b) ¿y si además el envío debe poder cambiar en ejecución entre push/SMS/email según preferencias del usuario? Relaciona tu respuesta con lo construido en el Bridge del módulo 3.

Solución 1:

Líneas de flujo escritas: cero — cargar, filtrar y agregar vienen heredados y con sus correcciones futuras incluidas. Ese es el dividendo del patrón.

Solución 2: en la base:

y en el método plantilla, la última línea de generar pasa a ser:

En InformeCsvCierre:

El PDF no toca nada: los hooks no obligan. (Y nota el orden: el hook va después de distribuir en la plantilla, no dentro de cada distribuir — el momento de llamada es propiedad del esqueleto.)

Solución 3: (a) Template Method: esqueleto fijo, un solo paso variable (componer), variantes estables — plantilla con componer() abstracto, exactamente la jugada esbozada en la sección de reencuentros; (b) el eje del canal debe cambiar en ejecución y por usuario: eso no puede fijarlo la herencia — y es justo lo que el Bridge ya resolvió: la abstracción Notificacion (donde puede vivir el método plantilla con componer variable por herencia) delega el envío en un CanalEnvio compuesto e intercambiable. Es decir: la respuesta correcta es ambos, cada uno en su eje — plantilla para el flujo y sus pasos por tipo, composición para el canal. Los ejes de variación independientes piden composición; los pasos de un flujo fijo toleran herencia.

Template Method pone el flujo común bajo un dueño único: InformeCierre.generar(...) fija el esqueleto — cargar, agregar, ¿generar?, formatear, distribuir — como método final, la lógica compartida vive una sola vez, y cada variante (PDF, CSV, email, y el JSON del ejercicio) aporta solo su diferencia, invocada por la base cuando toca: Hollywood en estado puro, la misma inversión de control con la que te hablan los frameworks que usas a diario. Y quedó trazada la tercera frontera de Strategy: pasos de un flujo fijo → herencia y plantilla; algoritmos completos, combinables o cambiantes en caliente → composición y estrategias.

Queda un último patrón en el catálogo de comportamiento, y ataca el problema más retorcido de todos: añadir operaciones nuevas a una jerarquía estable sin tocarla. La carta Composite lleva dos módulos acumulando pretendientes — exportar a JSON, calcular alérgenos, auditar precios — y meter cada operación dentro de Plato y SeccionCarta las convertiría en cajones de sastre. La solución exige el truco técnico más elegante del GoF: el double dispatch. Nos vemos en Visitor.