GoF Design Patterns: Introduction — Pattern Structure, MVC Case Study, and Catalog Organization
This chapter introduces the concept of design patterns in object-oriented software, defines the template used to describe each pattern, walks through MVC as a motivating example of multiple patterns working together, catalogs all 23 GoF patterns with one-line intents, and classifies them by purpose (creational/structural/behavioral) and scope (class/object). It also begins discussing how patterns solve fundamental OO design problems: finding appropriate objects, determining granularity, specifying interfaces, and specifying implementations.
Key Concepts
Design pattern definition: A named description of communicating objects and classes customized to solve a general design problem in a particular context — not as low-level as data structures, not as high-level as full application designs.
Pattern consequences: Space/time trade-offs, language/implementation issues, and impact on flexibility, extensibility, and portability. Must be listed explicitly.
Language influence on patterns: Patterns assume Smalltalk/C++-level features. Some patterns (e.g., Visitor) become unnecessary in languages with richer features (e.g., CLOS multi-methods). What counts as a "pattern" vs. a primitive depends on the language.
MVC as pattern composition: Model/View/Controller demonstrates Observer (subscribe/notify decoupling), Composite (nested views), and Strategy (swappable controllers), plus Factory Method (default controller) and Decorator (scrolling).
Object interface vs. implementation: An object's *type* refers to its interface (set of operation signatures); its *class* defines its implementation. Objects of different classes can share a type.
Dynamic binding and polymorphism: Run-time association of a request to an operation. Substitutability of objects with identical interfaces — the key mechanism for decoupling.
Abstract class: Defines a common interface; defers some/all implementation to subclasses; cannot be instantiated. Abstract operations are declared but not implemented.
Mixin class: Provides optional interface/functionality to other classes via multiple inheritance; not intended to be instantiated.
Class vs. interface inheritance: Class inheritance defines implementation reuse; interface inheritance (subtyping) defines when an object can be used in place of another. These are distinct concepts even though languages like C++ conflate them.
Encapsulation: Object's internal state is accessible only through its operations; representation is invisible from outside.
Commands and Syntax
Pattern description template (13 sections):
1. Pattern Name and Classification — succinct name + purpose/scope category
2. Intent — what it does, rationale, which problem it addresses
3. Also Known As — alternative names
4. Motivation — illustrative scenario
5. Applicability — when to apply, how to recognize the situation
6. Structure — OMT class diagrams + interaction diagrams
7. Participants — classes/objects and their responsibilities
8. Collaborations — how participants work together
9. Consequences — trade-offs, what can vary independently
Facade and Flyweight address object granularity at opposite ends (subsystems vs. fine-grained objects)
Abstract Factory and Builder create objects whose sole responsibility is creating other objects
Visitor and Command create objects whose sole responsibility is implementing requests
Composite often used with Iterator or Visitor
Prototype is often an alternative to Abstract Factory
Composite and Decorator have similar structure diagrams despite different intents
Decorator and Proxy both require identical interfaces to the wrapped object
Memento defines dual interfaces: restricted (for clients) and privileged (for the originator)
Exam-Relevant Points
There are exactly 23 GoF design patterns.
The two classification axes are purpose (creational, structural, behavioral) and scope (class, object). Most patterns are object-scoped.
Class-scoped patterns use inheritance (static, compile-time); object-scoped patterns use composition (dynamic, run-time).
MVC embodies three primary patterns: Observer, Composite, Strategy — plus Factory Method and Decorator.
The Observer pattern generalizes MVC's model-view decoupling: changes to one object affect many others without the changed object knowing their details.
The Strategy pattern generalizes MVC's controller mechanism: encapsulate an algorithm as an object so it can be replaced statically or dynamically.
An object's type = its interface; an object's class = its implementation. These are distinct.
Polymorphism = substitutability of objects supporting the same interface at run-time.
Dynamic binding = deferring the request-to-operation mapping until run-time.
Abstract classes cannot be instantiated; they define common interfaces for subclasses.
Mixin classes provide optional functionality via multiple inheritance.
The pattern template has 13 sections; "Known Uses" requires at least two examples from different domains.
Design patterns exist at a specific abstraction level — above reusable data structures, below full application/subsystem designs.
Strict real-world modeling is insufficient; patterns help discover non-obvious abstractions (e.g., objects representing algorithms or states) that make designs flexible.