Design patterns were not born in computing. They were born in architecture — the architecture of buildings and cities — at the hands of Christopher Alexander, and were adopted by the software community in the 1990s until they crystallized in one of the most influential books in the history of programming: Design Patterns, by the so-called Gang of Four. Knowing this history is not mere trivia: understanding why patterns emerged, what problem their authors were trying to solve, and how they have evolved since 1994 will help you use them with judgment, know which parts of the original catalog have aged, and recognize patterns where they live today: inside the languages and frameworks you use every day.

1. Christopher Alexander: patterns in architecture
2. The leap to software: from OOPSLA to the Gang of Four
3. Design Patterns (1994): the book that changed everything
4. Later evolution: POSA, Fowler and enterprise patterns
5. Patterns in modern frameworks and languages
6. Why are they still relevant 30 years later?

In the 1970s, the Austrian-British architect Christopher Alexander (1936–2022), a professor at Berkeley, asked himself an apparently simple question: why do some human-made places — a village square, a courtyard, a café with large windows — feel alive and pleasant, while others, technically correct, feel cold and inhospitable?

His answer was that good spaces repeat certain configurations that resolve recurring tensions between people and their environment. He called each of those configurations a pattern, and documented them in two seminal works:

• A Pattern Language (1977): a catalog of 253 architecture and urban-planning patterns, from the scale of a region down to a corner of a room. Each pattern has a name (for example, "Light on Two Sides of Every Room"), and describes the context, the conflicting forces and the solution.
• The Timeless Way of Building (1979): the theory underpinning the catalog, where his most quoted definition appears:

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Notice that this sentence from 1977, written about buildings, precisely describes what we saw in the previous lesson about software patterns: a reusable solution that is never identical, always adapted to the context.

Two of Alexander's ideas proved especially fertile for software:

• Patterns connect to form a language. They are not loose index cards: a large-scale pattern (a square) creates the context where smaller patterns apply (arcades, sunlit benches). The same happens in software: patterns combine and call upon one another.
• The problem–forces–solution format. The discipline of documenting why a solution works, and not just what it looks like, is Alexander's great methodological legacy.

In the late 1980s, several object-oriented programming researchers read Alexander and saw the parallel. The main milestones:

The book's four authors are universally known as the Gang of Four, abbreviated GoF. When you hear "the GoF patterns" or "the GoF book", it refers to them and their catalog.

An important detail: the GoF did not invent the patterns they documented. They discovered and distilled them by observing well-designed real systems (graphical frameworks such as ET++ and InterViews, Smalltalk, document editors...). That is the essence of pattern work: patterns are harvested from experience, not invented on a whiteboard.

The GoF book documents 23 patterns of object-oriented design, each with the standardized template we saw in the previous lesson (intent, motivation, applicability, structure, participants, consequences, implementation...). The original examples are in C++ and Smalltalk, the dominant object-oriented languages of the time.

Why was it so influential? Because of three contributions that remain valid:

1. It created a shared vocabulary. Before 1994, every team reinvented and renamed the same structures. Afterwards, "Observer", "Factory Method" or "Decorator" became words in the profession's common language, present in job interviews, documentation and class names in the standard libraries.
2. It raised the level of the design conversation. It made it possible to talk about complete class architectures ("here we have a Composite traversed by a Visitor") instead of describing things class by class.
3. It distilled principles into applicable solutions. The book opens with two maxims we will study in depth in the lesson Design Principles: "program to an interface, not an implementation" and "favor object composition over class inheritance". The 23 patterns are, to a large extent, concrete applications of those two ideas.

The book organized its 23 patterns into three families (creational, structural and behavioral) that remain the reference classification; we will look at it in detail in the lesson Classification of Design Patterns, and it is also the structure of modules 2, 3 and 4 of this course.

Its impact was enormous: it is one of the best-selling and most-cited technical books in the history of software, and in 2005 its authors received the ACM SIGPLAN Programming Languages Achievement Award for it.

The GoF's success opened a very productive era: the community set about harvesting patterns at other levels and in other domains. The milestones most worth knowing:

The Pattern-Oriented Software Architecture series (POSA, 5 volumes, started by Frank Buschmann and others in 1996) moved up the scale: from class design to the architecture of entire systems. POSA gave us names that are ubiquitous today:

• Layers: the presentation / business / persistence separation that nearly every application uses, including PideYa.
• Model-View-Controller (MVC): documented as an architectural pattern (the original idea came from Smalltalk, years earlier).
• Broker, Pipes and Filters, Microkernel... and, in later volumes, concurrency patterns such as Reactor or Half-Sync/Half-Async.

Martin Fowler published Patterns of Enterprise Application Architecture (PoEAA) in 2002, focused on the typical problems of business applications: data access, transactions, web presentation. If you have used an ORM such as Hibernate/JPA, you have used his patterns without knowing it:

• Repository and Data Mapper: separating the domain from the database (this is how the Spring Data repositories that PideYa might use to store orders work).
• Unit of Work: grouping changes and committing them together (the heart of a JPA session).
• Domain Model, Service Layer, Lazy Load, Active Record...

In parallel, catalogs appeared for other domains: Enterprise Integration Patterns (Hohpe and Woolf, 2003) for messaging between systems, concurrent programming patterns, and more recently pattern catalogs for microservices and distributed systems (Circuit Breaker, Saga, API Gateway...). We will not develop them now: module 6 of this course is devoted precisely to these modern patterns.

Since the 2000s, patterns have followed two complementary paths:

Today you rarely implement certain patterns by hand, because the framework already ships them built in. Some examples you will recognize when we study each pattern:

An interesting phenomenon: what requires a pattern in one language is a native feature in another. Some patterns are said to be "symptoms" of what a language lacks:

• The lambdas and method references of Java 8+ make trivial what used to require entire Strategy or Command classes.
• Java's enums offer the most robust way to write a Singleton (you will see it in module 2).
• Languages with first-class functions (JavaScript, Python, Kotlin) barely need certain behavioral patterns in their classic form.

This does not mean patterns "have died": it means the problem still exists and is worth knowing, even if the solution is sometimes one line of a modern language instead of three classes. Knowing that that lambda is a Strategy lets you talk about it, document it and evolve it with judgment.

It is fair to ask whether a 1994 catalog, with examples in C++, still deserves a course today. The answer is yes, for these reasons:

1. The problems have not changed. We still need to create objects without coupling to their classes, notify changes without knowing the interested parties, or add behavior without touching code that works. The design forces are the same in PideYa as in a document editor from 1993.
2. The vocabulary is now infrastructure of the profession. The GoF names appear in the documentation of Java, Spring or Android, in code reviews and in technical interviews. Not knowing them leaves you out of the conversation.
3. They are the gateway to design. Studying patterns is the most effective way to internalize design principles (we will see them in the next lesson): each pattern is a principle made flesh.
4. They have shown they know how to evolve. The pattern movement did not freeze in 1994: it produced POSA, PoEAA, the integration patterns and today the microservices patterns. The practice of documenting problem-forces-solution remains alive and keeps generating new catalogs.
5. With nuances. Their relevance is not uniform: some of the 23 are used daily, while others have been relegated or are today considered problematic in their classic form. We will point out these nuances pattern by pattern, and module 5 devotes a whole lesson to anti-patterns.

• Thinking the GoF invented the patterns. They documented them: patterns are harvested from real systems that work. That is why a solution from your team, however good, only becomes a pattern once it has been repeated and validated in multiple contexts.
• Treating the 1994 book as untouchable dogma. The catalog reflects the state of the art of 1990s C++/Smalltalk. The problems remain valid; some concrete solutions are expressed differently today (lambdas, enums, frameworks). Study the problem, not just the literal solution.
• Ignoring everything after the GoF. If you only know the 23 classics, you will lack the vocabulary of architecture (POSA), enterprise (Fowler) and distributed systems that dominates development today. This course gives you the complete map: GoF in modules 2–4 and the modern material in module 6.
• Getting the chronology wrong. A typical slip in interviews: Alexander (architecture, 1977) → Beck/Cunningham (OOPSLA, 1987) → GoF (1994) → POSA (1996) → Fowler (2002). Having the sequence clear helps you place each catalog at its level of abstraction.
• Tip: browse (even if only out of curiosity) the table of contents of A Pattern Language. Seeing patterns like "Window Place" or "Small Public Squares" described in the same format as Observer is the best way to internalize that a pattern is problem+forces+solution, not code.

Take Alexander's quote ("use this solution a million times over, without ever doing it the same way twice") and explain, using the PideYa notification example from the previous lesson, what it would mean in practice: what would be the reusable "solution" and what would change in each concrete application?

Match each PideYa problem with the historical catalog where you would look for the solution (GoF 1994, POSA, Fowler's PoEAA, or microservices catalogs):

1. Deciding how to split the application into presentation, business and persistence layers.
2. Adding notification channels (email, SMS, push) without modifying the Order class.
3. Storing and retrieving orders from the database without the domain knowing any SQL.
4. Preventing an outage of the payment service from cascading down the whole platform.

Without having studied any pattern yet, find two class or interface names in the Java JDK that literally contain the name of a GoF pattern (hint: look in java.util and java.io). Explain what this suggests about the relationship between the 1994 catalog and today's platforms.

Solution 1: The reusable "solution" is the conceptual structure: the order does not know its interested parties; instead there is a subscription mechanism through which interested parties sign up and receive notifications. What changes in each application: the class names (in PideYa they would come from the ordering domain), which events are notified (status changes), who subscribes (push, SMS, statistics), the language, and even details such as whether notification is synchronous or asynchronous. Two teams applying the same solution will produce different code: a million uses, none identical.

Solution 2:

1. POSA — the separation into layers is the Layers architectural pattern, documented in POSA 1.
2. GoF 1994 — it is a class-design problem (decoupled notification), the territory of the classic catalog (we will see it in module 4).
3. PoEAA (Fowler) — separating domain and persistence is the terrain of Repository / Data Mapper / Unit of Work.
4. Microservices / distributed-systems catalogs — resilience against failures of remote services (Circuit Breaker style); module 6 will cover it.

Solution 3: The two clearest cases are java.util.Iterator (Iterator pattern) and java.util.Observer/java.util.Observable (Observer pattern; deprecated since Java 9, which is itself illustrative: the platform keeps the pattern but improved the implementation). Also valid: java.sql.DriverManager.getConnection(...) as a factory, or the *Builder classes such as StringBuilder (with caveats, as it is not the full GoF Builder). What it suggests: the authors of modern platforms adopted the GoF vocabulary to the point of using it in public APIs; knowing the patterns is knowing the language the standard libraries are written in.

You now know the complete lineage of design patterns: Christopher Alexander's intuition about spaces that work, the leap to software by Beck and Cunningham in 1987, the crystallization into the Gang of Four's 23 patterns in 1994, and the later expansion into architecture (POSA), enterprise applications (Fowler) and today's distributed systems. Above all, you know why they remain relevant: design problems do not expire, even as the solutions modernize.

A key idea has surfaced in the GoF story: their 23 patterns are concrete applications of a handful of design principles ("program to interfaces", "favor composition..."). Before studying any pattern we need to master those principles, because they are the yardstick for judging any design. That is the goal of the next lesson: Design Principles: SOLID and Other Foundations.