GoF Design Patterns
Details
- Full Name
-
Gang of Four Design Patterns
- Also known as
-
Design Patterns, Gang of Four Patterns
Core Concepts:
- Creational Patterns
-
Abstract Factory, Builder, Factory Method, Prototype, Singleton — object creation mechanisms
- Structural Patterns
-
Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy — object composition and relationships
- Behavioral Patterns
-
Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor — object interaction and responsibility
- Pattern language
-
Shared vocabulary for communicating recurring design problems and proven solutions
- Composition over inheritance
-
Favor object composition for flexibility over rigid class hierarchies
- Program to an interface
-
Depend on abstractions rather than concrete implementations
- Design for change
-
Identify what varies in your design and encapsulate it
- Key Proponents
-
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ("Design Patterns: Elements of Reusable Object-Oriented Software", 1994)
When to Use:
-
Object-oriented design requiring proven solutions to recurring problems
-
Communicating design decisions using a shared vocabulary
-
Teaching object-oriented design principles through concrete examples
-
Refactoring code to increase flexibility and reusability
Related Anchors:
-
SOLID Principles - Design principles that GoF patterns help implement
-
Fowler Patterns - Enterprise application architecture patterns (complementary scope)
-
Clean Architecture - Architectural style leveraging GoF principles
Criticism:
-
Peter Norvig, "Design Patterns in Dynamic Languages" (1996/1998) — 16 of the 23 patterns have a "qualitatively simpler implementation" in Lisp or Dylan than in C++, or vanish into the language entirely: many patterns compensate for missing language features rather than capture universal design wisdom
-
Paul Graham, "Revenge of the Nerds" (2002) — recurring patterns may be evidence of "the human compiler at work": "When I see patterns in my programs, I consider it a sign of trouble", a sign the language’s abstractions are not powerful enough
-
The authors themselves treat the catalog as a 1994 snapshot, not a closed canon: in the 2009 InformIT interview they discuss how they would reorganize and trim it today (see also the Criticism on Singleton)