Zum Inhalt springen

Design Patterns and the Gang of Four

Zusammenfassung

In 1994, four software engineers published a book called Design Patterns: Elements of Reusable Object-Oriented Software. The authors — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — became known collectively as the “Gang of Four,” and their book became one of the most influential in computing history, introducing a shared vocabulary for recurring solutions to common software design problems. The 23 patterns it described — Singleton, Observer, Factory Method, Decorator, and nineteen others — gave developers a language to communicate design ideas at a level above code, transforming how the profession talked about software structure. The book’s influence also attracted substantial criticism: patterns were accused of being workarounds for language limitations, of encouraging overengineering, and of creating a culture of dogmatic pattern-matching rather than clear thinking. Both the influence and the criticism are legitimate. The Gang of Four book is the record of a conversation the software engineering profession needed to have about design.

Christopher Alexander and the Origin of the Concept

The concept of design patterns in software was adapted from Christopher Alexander, an architect who in 1977 published A Pattern Language, describing 253 recurring patterns in urban design and architecture — from the scale of cities to the scale of windows. Alexander’s patterns were solutions to problems that recurred across different contexts, each capturing a relationship between forces that was applicable whenever those forces arose.

Ward Cunningham and Kent Beck (the later developers of wiki software and Extreme Programming, respectively) presented a paper, “Using Pattern Languages for Object-Oriented Programs,” at the OOPSLA-87 Workshop on Specification and Design for Object-Oriented Programming, applying Alexander’s pattern language concept to Smalltalk programs — a system of five patterns they had used to design window-based user interfaces at Tektronix. The idea attracted immediate interest in the object-oriented programming community. (Bruce Anderson’s “Architecture Handbook” workshops, which gathered many of the pattern pioneers, followed at OOPSLA from 1990 onward.)

Alexander’s key insight, transferred to software, was that patterns were not algorithms or components — they were descriptions of successful solutions that could be applied in varying contexts. A pattern named the forces at play in a problem, described a solution that balanced those forces, and explained the trade-offs. Patterns were not recipes; they required judgment in application.

The Four Authors

The Gang of Four book grew from a 1990 OOPSLA workshop on object-oriented design, where Erich Gamma presented ideas he had been developing in his PhD thesis at the University of Zurich. Gamma, working on designing the ET++ graphical framework, had identified recurring design structures he wanted to describe systematically.

John Vlissides and Ralph Johnson were academic researchers in object-oriented design. Richard Helm was an industry practitioner. All four had worked extensively on object-oriented software and had independently encountered the same problem: no vocabulary existed to discuss design at the level of how objects collaborated, above the level of individual classes and methods.

The collaboration on the book began at an OOPSLA workshop in 1990 and continued across four years of writing and refinement. The authors collected patterns from their own experience, from published object-oriented code, and from other researchers in the community. They wrote, critiqued, revised, and tested each pattern description against real implementations. The process was exhausting — Vlissides later wrote about the difficulty of sustaining creative work over four years — but produced a catalog of unusual quality.

The 23 Patterns

The book organized patterns into three categories:

Creational patterns — how objects are created:

  • Abstract Factory: create families of related objects without specifying concrete classes
  • Builder: separate the construction of a complex object from its representation
  • Factory Method: define an interface for creating objects but let subclasses decide which class to instantiate
  • Prototype: create new objects by copying an existing instance
  • Singleton: ensure a class has only one instance and provide global access to it

Structural patterns — how objects are composed:

  • Adapter: convert the interface of a class into another interface clients expect
  • Bridge: separate an abstraction from its implementation so both can vary independently
  • Composite: compose objects into tree structures to represent part-whole hierarchies
  • Decorator: attach additional responsibilities to an object dynamically
  • Facade: provide a simplified interface to a complex subsystem
  • Flyweight: use sharing to support large numbers of fine-grained objects efficiently
  • Proxy: provide a surrogate or placeholder for another object to control access

Behavioral patterns — how objects communicate:

  • Chain of Responsibility: pass requests along a chain of handlers
  • Command: encapsulate a request as an object
  • Interpreter: define a grammar for a language and provide an interpreter
  • Iterator: provide a way to access elements of a collection without exposing its structure
  • Mediator: define an object that encapsulates how a set of objects interact
  • Memento: capture and restore an object’s state
  • Observer: define a one-to-many dependency so that when one object changes state, dependents are notified
  • State: allow an object to alter its behavior when its internal state changes
  • Strategy: define a family of algorithms, encapsulate each one, and make them interchangeable
  • Template Method: define the skeleton of an algorithm, deferring steps to subclasses
  • Visitor: represent an operation to be performed on elements of an object structure

The Book’s Impact

Design Patterns sold over half a million copies in English and was translated into dozens of languages. It became the book that distinguished junior from senior developers — a reference that practitioners cited in design discussions and job interviews. The patterns acquired names that developers used in technical conversation without further explanation: “use an Observer here,” “wrap it in a Decorator,” “that’s a Strategy pattern.”

The vocabulary impact was the book’s most durable contribution. Before Design Patterns, architects describing software structure had to describe it in terms of code or metaphor. After it, “make it an Observer” conveyed a specific structure — a subject that maintained a list of dependents and notified them on state changes — without writing a line of code. The names became conceptual primitives in the profession’s shared language.

The patterns influenced programming language design. The Iterator pattern described a solution that later languages (Python, Ruby, C#, Java) built into the language itself as for-in loops and generators. The Observer pattern influenced event-driven programming models and reactive frameworks. Factory methods influenced dependency injection frameworks. The languages absorbed the patterns, which is one measure of their accuracy.

The Criticism

The patterns attracted several lines of criticism, some substantive:

Language inadequacy: Peter Norvig published a widely cited analysis in 1996 showing that 16 of the 23 Gang of Four patterns were either invisible or trivially simple in dynamic languages like Lisp and Dylan. The Visitor pattern, for example, required elaborate boilerplate in Java or C++ but was simply function dispatch in a language with dynamic multiple dispatch. The implication was that the patterns documented workarounds for specific language limitations rather than universal design solutions. This criticism was accurate for some patterns and less accurate for others.

Overengineering: Applying patterns to every design decision produced code of unnecessary complexity. An application with one configuration source did not need an Abstract Factory to create configuration objects. The pattern was designed for situations requiring multiple interchangeable implementations; applying it where only one implementation would ever exist added complexity without benefit. A culture emerged of pattern-matching — identifying which pattern to apply — before fully understanding the problem, leading to code structured around patterns rather than requirements.

Singleton abuse: The Singleton pattern is among the most criticized in the catalog. A Singleton guarantees that exactly one instance of a class exists and provides a global access point — but global state creates hidden dependencies between components, making code harder to test and understand. Most contemporary software design advice recommends dependency injection (pass the shared instance where it is needed) over Singleton, unless the uniqueness constraint is itself a requirement.

The “factory” naming confusion: “Factory” is used loosely in software to mean any object that creates other objects, despite the Gang of Four distinguishing Abstract Factory, Factory Method, and Builder. The imprecision created communication confusion — developers using “factory” to mean different things while believing they shared a vocabulary.

Beyond the Gang of Four

The Gang of Four book triggered a wave of pattern literature. Domain-specific pattern catalogs appeared for enterprise software (Martin Fowler’s Patterns of Enterprise Application Architecture, 2002), distributed systems (Gregor Hohpe’s Enterprise Integration Patterns, 2003), concurrent programming, user interfaces, and dozens of other domains.

Ward Cunningham’s wiki software was designed specifically to facilitate pattern capture and discussion — the wiki was originally a pattern repository. The Portland Pattern Repository (c2.com) accumulated thousands of patterns and counter-patterns in collaborative wiki form from 1995 onward, many written or reviewed by the Gang of Four authors.

Refactoring — Martin Fowler’s Refactoring: Improving the Design of Existing Code (1999) — created a complementary vocabulary describing transformations from worse to better code structure. Where patterns described structures to aim for, refactorings described moves to get there.

Anti-patterns — notably Brown et al.’s AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) — described recurring bad solutions: structures that seemed reasonable but caused systematic problems. The Singleton’s anti-pattern characterization emerged partly from this literature.

The Gang of Four patterns have aged unevenly. Creational patterns have mostly been superseded by dependency injection frameworks. Structural patterns remain relevant. Behavioral patterns, especially Observer, Strategy, and Iterator, appear constantly in modern codebases, often without developers recognizing the name. The book’s lasting value is not the 23 patterns it described but the evidence it provides that software design can be discussed at a level above code — that the profession has a vocabulary, not just a syntax.

📚 Sources