Los patrones de diseño no nacieron en la informática. Nacieron en la arquitectura —la de edificios y ciudades— de la mano de Christopher Alexander, y fueron adoptados por la comunidad de software en los años 90 hasta cristalizar en uno de los libros más influyentes de la historia de la programación: Design Patterns, del llamado Gang of Four. Conocer esta historia no es mera cultura general: entender por qué surgieron los patrones, qué problema intentaban resolver sus autores y cómo han evolucionado desde 1994 te ayudará a usarlos con criterio, a saber qué partes del catálogo original han envejecido y a reconocer patrones allí donde hoy viven: dentro de los lenguajes y frameworks que usas a diario.

1. Christopher Alexander: patrones en la arquitectura
2. El salto al software: de OOPSLA al Gang of Four
3. Design Patterns (1994): el libro que lo cambió todo
4. La evolución posterior: POSA, Fowler y los patrones de empresa
5. Patrones en los frameworks y lenguajes modernos
6. ¿Por qué siguen vigentes 30 años después?

En los años 70, el arquitecto austríaco-británico Christopher Alexander (1936–2022), profesor en Berkeley, se hizo una pregunta aparentemente simple: ¿por qué algunos lugares construidos por el ser humano —una plaza de pueblo, un patio, un café con ventanales— nos resultan vivos y agradables, mientras que otros, técnicamente correctos, resultan fríos e inhóspitos?

Su respuesta fue que los buenos espacios repiten ciertas configuraciones que resuelven tensiones recurrentes entre las personas y su entorno. A cada una de esas configuraciones la llamó patrón, y las documentó en dos obras fundamentales:

• A Pattern Language (1977): un catálogo de 253 patrones de arquitectura y urbanismo, desde la escala de una región hasta la de un rincón de una habitación. Cada patrón tiene nombre (por ejemplo, "Luz en dos lados de cada habitación"), describe el contexto, las fuerzas en conflicto y la solución.
• The Timeless Way of Building (1979): la teoría que sustenta el catálogo, donde aparece su definición más citada:

«Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y describe el núcleo de la solución a ese problema, de tal manera que puedas usar esa solución un millón de veces sin hacerlo nunca dos veces de la misma manera.»

Fíjate en que esta frase de 1977, escrita sobre edificios, describe con precisión lo que vimos en la lección anterior sobre patrones de software: solución reutilizable pero nunca idéntica, siempre adaptada al contexto.

Dos ideas de Alexander resultaron especialmente fértiles para el software:

• Los patrones se conectan formando un lenguaje. No son fichas sueltas: un patrón de gran escala (una plaza) crea el contexto donde aplican patrones menores (soportales, bancos al sol). En software ocurre igual: los patrones se combinan y se llaman unos a otros.
• El formato problema–fuerzas–solución. La disciplina de documentar por qué funciona una solución, y no solo cómo es, es la gran herencia metodológica de Alexander.

A finales de los 80, varios investigadores de la programación orientada a objetos leyeron a Alexander y vieron el paralelismo. Los hitos principales:

A los cuatro autores del libro se les conoce universalmente como el Gang of Four («la banda de los cuatro»), abreviado GoF. Cuando oigas «los patrones del GoF» o «el libro del GoF», se refiere a ellos y a su catálogo.

Un detalle importante: el GoF no inventó los patrones que documentó. Los descubrió y destiló observando sistemas reales bien diseñados (frameworks gráficos como ET++ e InterViews, Smalltalk, editores de documentos...). Esa es la esencia del trabajo con patrones: se cosechan de la experiencia, no se inventan en una pizarra.

El libro del GoF documenta 23 patrones de diseño orientado a objetos, cada uno con la ficha estandarizada que vimos en la lección anterior (intención, motivación, aplicabilidad, estructura, participantes, consecuencias, implementación...). Los ejemplos originales están en C++ y Smalltalk, los lenguajes orientados a objetos dominantes de la época.

¿Por qué fue tan influyente? Por tres aportaciones que siguen vigentes:

1. Creó un vocabulario compartido. Antes de 1994, cada equipo reinventaba y renombraba las mismas estructuras. Después, "Observer", "Factory Method" o "Decorator" se convirtieron en palabras del idioma común de la profesión, presentes en entrevistas de trabajo, documentación y nombres de clases de las librerías estándar.
2. Elevó el nivel del discurso sobre diseño. Permitió hablar de arquitecturas de clases completas ("aquí hay un Composite recorrido por un Visitor") en lugar de describir clase a clase.
3. Destiló principios en soluciones aplicables. El libro abre con dos máximas que estudiaremos a fondo en la lección Principios de Diseño: «programa contra una interfaz, no contra una implementación» y «favorece la composición de objetos sobre la herencia de clases». Los 23 patrones son, en gran medida, aplicaciones concretas de esas dos ideas.

El libro organizó sus 23 patrones en tres familias (creacionales, estructurales y de comportamiento) que siguen siendo la clasificación de referencia; la veremos en detalle en la lección Clasificación de los Patrones de Diseño, y es también la estructura de los módulos 2, 3 y 4 de este curso.

El impacto fue enorme: es uno de los libros técnicos más vendidos y citados de la historia del software, y en 2005 sus autores recibieron por él el premio Programming Languages Achievement Award de ACM SIGPLAN.

El éxito del GoF abrió una etapa muy productiva: la comunidad se dedicó a cosechar patrones en otros niveles y dominios. Los hitos que más te conviene conocer:

La serie Pattern-Oriented Software Architecture (POSA, 5 volúmenes, iniciada por Frank Buschmann y otros en 1996) subió la escala: del diseño de clases a la arquitectura de sistemas completos. De POSA salen nombres que hoy son omnipresentes:

• Layers (arquitectura en capas): la separación presentación / negocio / persistencia que usa casi cualquier aplicación, incluida PideYa.
• Model-View-Controller (MVC): documentado como patrón arquitectónico (la idea original venía de Smalltalk, años antes).
• Broker, Pipes and Filters, Microkernel... y en volúmenes posteriores, patrones de concurrencia como Reactor o Half-Sync/Half-Async.

Martin Fowler publicó en 2002 Patterns of Enterprise Application Architecture (PoEAA), centrado en los problemas típicos de las aplicaciones de negocio: acceso a datos, transacciones, presentación web. Si has usado un ORM como Hibernate/JPA, has usado sus patrones sin saberlo:

• Repository y Data Mapper: separar el dominio de la base de datos (así funcionan los repositorios de Spring Data que podría usar PideYa para guardar pedidos).
• Unit of Work: agrupar cambios y confirmarlos juntos (el corazón de una sesión de JPA).
• Domain Model, Service Layer, Lazy Load, Active Record...

En paralelo aparecieron catálogos para otros dominios: Enterprise Integration Patterns (Hohpe y Woolf, 2003) para mensajería entre sistemas, patrones de programación concurrente, y más recientemente catálogos de patrones para microservicios y sistemas distribuidos (Circuit Breaker, Saga, API Gateway...). No los desarrollaremos ahora: el módulo 6 de este curso está dedicado precisamente a estos patrones modernos.

Desde los 2000, los patrones han seguido dos caminos complementarios:

Hoy rara vez implementas ciertos patrones a mano, porque el framework ya los trae hechos. Algunos ejemplos que reconocerás cuando estudiemos cada patrón:

Un fenómeno interesante: lo que en un lenguaje exige un patrón, en otro es una característica nativa. Se dice que algunos patrones son «síntomas» de lo que le falta a un lenguaje:

• Las lambdas y referencias a métodos de Java 8+ hacen trivial lo que antes requería clases enteras de Strategy o Command.
• Los enum de Java ofrecen la forma más robusta de escribir un Singleton (lo verás en el módulo 2).
• Lenguajes con funciones de primera clase (JavaScript, Python, Kotlin) apenas necesitan ciertos patrones de comportamiento en su forma clásica.

Esto no significa que los patrones "hayan muerto": significa que el problema sigue existiendo y que conviene conocerlo, aunque la solución a veces sea una línea de lenguaje moderno en lugar de tres clases. Saber que esa lambda es una Strategy te permite hablar de ella, documentarla y evolucionarla con criterio.

Cabe preguntarse si un catálogo de 1994, con ejemplos en C++, sigue mereciendo un curso en la actualidad. La respuesta es sí, por estas razones:

1. Los problemas no han cambiado. Seguimos necesitando crear objetos sin acoplarnos a sus clases, notificar cambios sin conocer a los interesados o añadir comportamiento sin tocar código que funciona. Las fuerzas de diseño son las mismas en PideYa que en un editor de documentos de 1993.
2. El vocabulario es ya infraestructura de la profesión. Los nombres del GoF aparecen en la documentación de Java, Spring o Android, en las revisiones de código y en las entrevistas técnicas. No conocerlos te deja fuera de la conversación.
3. Son la puerta de entrada al diseño. Estudiar patrones es la forma más eficaz de interiorizar los principios de diseño (los veremos en la próxima lección): cada patrón es un principio hecho carne.
4. Han demostrado saber evolucionar. El movimiento de patrones no se congeló en 1994: produjo POSA, PoEAA, los patrones de integración y hoy los de microservicios. La práctica de documentar problema-fuerzas-solución sigue viva y generando catálogos nuevos.
5. Con matices. La vigencia no es uniforme: algunos de los 23 se usan a diario y otros han quedado relegados o se consideran hoy problemáticos en su forma clásica. Señalaremos estos matices patrón a patrón, y el módulo 5 dedica una lección entera a los antipatrones.

• Pensar que el GoF inventó los patrones. Los documentó: los patrones se cosechan de sistemas reales que funcionan. Por eso una solución de tu equipo, por buena que sea, solo se convierte en patrón cuando se ha repetido y validado en múltiples contextos.
• Tratar el libro de 1994 como dogma intocable. El catálogo refleja el estado del arte de C++/Smalltalk de los 90. Los problemas siguen vigentes; algunas soluciones concretas se expresan hoy de otra manera (lambdas, enums, frameworks). Estudia el problema, no solo la solución literal.
• Ignorar todo lo posterior al GoF. Si solo conoces los 23 clásicos, te faltará el vocabulario de arquitectura (POSA), de empresa (Fowler) y de sistemas distribuidos que domina el desarrollo actual. Este curso te da el mapa completo: GoF en los módulos 2–4 y lo moderno en el módulo 6.
• Confundir la cronología. Un desliz típico en entrevistas: Alexander (arquitectura, 1977) → Beck/Cunningham (OOPSLA, 1987) → GoF (1994) → POSA (1996) → Fowler (2002). Tener clara la secuencia ayuda a situar cada catálogo en su nivel de abstracción.
• Consejo: hojea (aunque sea por curiosidad) el índice de A Pattern Language. Ver patrones como "Ventana al sur" o "Plaza pequeña" descritos con el mismo formato que Observer es la mejor forma de interiorizar que un patrón es problema+fuerzas+solución, no código.

Toma la cita de Alexander («usar esa solución un millón de veces sin hacerlo nunca dos veces de la misma manera») y explica, con el ejemplo de las notificaciones de PideYa de la lección anterior, qué significaría en la práctica: ¿qué sería «la solución» reutilizable y qué cambiaría en cada aplicación concreta?

Relaciona cada problema de PideYa con el catálogo histórico donde buscarías la solución (GoF 1994, POSA, PoEAA de Fowler, o catálogos de microservicios):

1. Decidir cómo separar la aplicación en capas de presentación, negocio y persistencia.
2. Añadir canales de notificación (email, SMS, push) sin modificar la clase Pedido.
3. Guardar y recuperar pedidos de la base de datos sin que el dominio conozca SQL.
4. Evitar que la caída del servicio de pagos tumbe en cascada toda la plataforma.

Sin haber estudiado aún ningún patrón, localiza en el JDK de Java dos nombres de clase o interfaz que contengan literalmente el nombre de un patrón del GoF (pista: busca entre java.util y java.io). Indica qué sugiere esto sobre la relación entre el catálogo de 1994 y las plataformas actuales.

Solución 1: «La solución» reutilizable es la estructura conceptual: que el pedido no conozca a sus interesados, sino que exista un mecanismo de suscripción por el que los interesados se apuntan y reciben avisos. Lo que cambia en cada aplicación: los nombres de las clases (en PideYa serían del dominio de pedidos), qué eventos se notifican (cambios de estado), quiénes se suscriben (push, SMS, estadísticas), el lenguaje, e incluso detalles como si la notificación es síncrona o asíncrona. Dos equipos que apliquen la misma solución producirán códigos distintos: un millón de usos, ninguno idéntico.

Solución 2:

1. POSA — la separación en capas es el patrón arquitectónico Layers, documentado en POSA 1.
2. GoF 1994 — es un problema de diseño de clases (notificación desacoplada), territorio del catálogo clásico (lo veremos en el módulo 4).
3. PoEAA (Fowler) — separar dominio y persistencia es el terreno de Repository / Data Mapper / Unit of Work.
4. Catálogos de microservicios / sistemas distribuidos — resiliencia ante fallos de servicios remotos (tipo Circuit Breaker); lo tratará el módulo 6.

Solución 3: los dos casos más claros son java.util.Iterator (patrón Iterator) y java.util.Observer/java.util.Observable (patrón Observer; deprecados desde Java 9, lo cual es en sí ilustrativo: la plataforma mantiene el patrón pero mejoró la implementación). También valen java.sql.DriverManager.getConnection(...) como fábrica o los *Builder como StringBuilder (con matices, pues no es el Builder del GoF completo). Lo que sugiere: los autores de las plataformas modernas adoptaron el vocabulario del GoF hasta el punto de usarlo en las APIs públicas; conocer los patrones es conocer el idioma en que están escritas las librerías estándar.

Ya conoces el linaje completo de los patrones de diseño: la intuición de Christopher Alexander sobre los espacios que funcionan, el salto al software de Beck y Cunningham en 1987, la cristalización en los 23 patrones del Gang of Four en 1994, y la expansión posterior hacia la arquitectura (POSA), las aplicaciones de empresa (Fowler) y los sistemas distribuidos actuales. Y, sobre todo, sabes por qué siguen vigentes: los problemas de diseño no caducan, aunque las soluciones se modernicen.

En la historia del GoF ha aparecido una idea clave: sus 23 patrones son aplicaciones concretas de unos pocos principios de diseño ("programa contra interfaces", "favorece la composición..."). Antes de estudiar ningún patrón necesitamos dominar esos principios, porque son el criterio con el que juzgar cualquier diseño. Es el objetivo de la próxima lección: Principios de Diseño: SOLID y Otros Fundamentos.