Design Patterns¶
Gamma, E., Helm, Johnson, & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
Cited by¶
28 citations across 27 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Abstraction
This sourceThe 23 'Gang of Four' reusable object-oriented design patterns.
- Archetype
- The Gang of Four's 23 patterns function exactly as narrative archetypes do: each is a stable structural template (roles, responsibilities, collaborations, problem-context-solution binding) that recurs across languages, codebases, and problem domains; each is instantiable in many specific ways with substantial surface variation (implementation language, specific algorithms, data-structure choices) while preserving the core pattern; each is recognized rapidly by developers who share the pattern vocabulary, enabling immediate knowledge transfer; each carries predictable properties, expected tradeoffs (Observer gains loose coupling at the cost of potential notification ordering issues), and characteristic failure modes.
This sourceThe 'Gang of Four' catalog of 23 reusable object-oriented design patterns; each is an abstract solution template (problem-context-solution, roles, collaborations) recognized and reused across languages and codebases. Substantiates the software-design-patterns-as-archetypes transfer claim on marker 010 (replaces Propp, which does not support it).
- The Gang of Four's 23 patterns function exactly as narrative archetypes do: each is a stable structural template (roles, responsibilities, collaborations, problem-context-solution binding) that recurs across languages, codebases, and problem domains; each is instantiable in many specific ways with substantial surface variation (implementation language, specific algorithms, data-structure choices) while preserving the core pattern; each is recognized rapidly by developers who share the pattern vocabulary, enabling immediate knowledge transfer; each carries predictable properties, expected tradeoffs (Observer gains loose coupling at the cost of potential notification ordering issues), and characteristic failure modes.
- Boundary
- Listed in the references but not attached to a specific claim.
- Callback
- Asynchronous computation — event handlers, completion notifications, deferred continuations, and the observer pattern, where a handler is registered and fired later by a system with visibility of the event.
This sourceCanonical reference for the Observer pattern and callback-style deferred invocation of registered handlers.
- Asynchronous computation — event handlers, completion notifications, deferred continuations, and the observer pattern, where a handler is registered and fired later by a system with visibility of the event.
- Compatibility
- Decomposition
- Listed in the references but not attached to a specific claim.
- Dependency
This sourceCatalog of 23 patterns; several (e.g., Dependency Inversion via abstractions, Observer) manage object dependencies.
- Design Patterns
- The pattern format—which names the pattern, describes problem and context, specifies solution structure, enumerates consequences and trade-offs, and provides documented uses—originates in Christopher Alexander's architectural pattern-language work (Alexander, 1977), achieved canonical formalization through Gamma, Helm, Johnson, and Vlissides' Design Patterns in software engineering (Gamma et al., 1994), and has since generalized across domains including software architecture, urban planning, user-interface design, pedagogy, organizational design, game design, and security engineering.
This sourceThe 'Gang of Four' book; establishes 23 canonical OO patterns and adapts Alexander's methodology to software.
- The pattern format—which names the pattern, describes problem and context, specifies solution structure, enumerates consequences and trade-offs, and provides documented uses—originates in Christopher Alexander's architectural pattern-language work (Alexander, 1977), achieved canonical formalization through Gamma, Helm, Johnson, and Vlissides' Design Patterns in software engineering (Gamma et al., 1994), and has since generalized across domains including software architecture, urban planning, user-interface design, pedagogy, organizational design, game design, and security engineering.
- Inheritance
- In object-oriented programming it is class inheritance, method override, the Liskov substitution principle, mixins and traits, and prototype-based inheritance.
This sourceSource of the 'favor composition over inheritance' design principle and the discussion of inheritance versus delegation.
- In object-oriented programming it is class inheritance, method override, the Liskov substitution principle, mixins and traits, and prototype-based inheritance.
- Interface
- The pattern—boundary, contract, asymmetric visibility, independent evolution—transfers across domains, exemplified by the catalog of structural interface patterns Gamma, Helm, Johnson, and Vlissides (1994) cataloged in their canonical work.
This sourceCanonical "Gang of Four" catalog of structural and behavioral interface patterns—Adapter, Facade, Bridge, Proxy, Observer—whose reasoning transfers across software, organizational, and engineering domains.
- The pattern—boundary, contract, asymmetric visibility, independent evolution—transfers across domains, exemplified by the catalog of structural interface patterns Gamma, Helm, Johnson, and Vlissides (1994) cataloged in their canonical work.
- Layered Accumulation
- Listed in the references but not attached to a specific claim.
- Layering
- Listed in the references but not attached to a specific claim.
- Minimalism
- Listed in the references but not attached to a specific claim.
- Modularity
- Orchestration
- The burden collapses from an unbounded web to a state machine plus n interfaces.
This sourceThe Mediator pattern replaces many-to-many interaction among peers with one relationship per participant once a mediator holds the interaction.
- The burden collapses from an unbounded web to a state machine plus n interfaces.
- Pattern (in Design)
- Listed in the references but not attached to a specific claim.
- Prototype Theory
- Software taxonomy and APIs. A typical use case anchors category membership for design patterns, library types, and framework genres; atypical uses are tolerated but flagged as such.
This sourceDocuments each design pattern with an Intent and Applicability describing its prototypical use case, against which atypical uses are judged.
- Software taxonomy and APIs. A typical use case anchors category membership for design patterns, library types, and framework genres; atypical uses are tolerated but flagged as such.
- Remapping
- In object-oriented programming, the same method name resolves to different implementations depending on dispatch context, the same code substrate hosting many behaviours.
This sourceStandard reference on polymorphism and dynamic dispatch resolving one method name to many implementations by context.
- In object-oriented programming, the same method name resolves to different implementations depending on dispatch context, the same code substrate hosting many behaviours.
- Role
- Programming to an interface rather than to an implementation is the engineering discipline of depending on the role rather than the occupant, a principle the Gang of Four (Gamma et al., 1994) elevate to the central organizing idea of reusable object-oriented design.
This sourceThe "Gang of Four" catalogue; elevates programming to an interface rather than an implementation — depending on the role (Observer, Mediator, Strategy) rather than the concrete occupant — to the central organizing idea of reusable object-oriented design, the engineering transfer of slot/occupant separation.
- Programming to an interface rather than to an implementation is the engineering discipline of depending on the role rather than the occupant, a principle the Gang of Four (Gamma et al., 1994) elevate to the central organizing idea of reusable object-oriented design.
- Task Interdependence
- Listed in the references but not attached to a specific claim.
- Type–Token Distinction
- A fleet of ten thousand identical valves does not require ten thousand descriptions of a valve; it requires one specification and ten thousand short records of position, hours, and condition.
This sourceThe Flyweight pattern stores context-independent intrinsic state once in the shared object and leaves context-dependent extrinsic state with each client, which is exactly the per-occurrence saving the passage describes.
- A fleet of ten thousand identical valves does not require ten thousand descriptions of a valve; it requires one specification and ten thousand short records of position, hours, and condition.
- Viewpoint
Domain-specific¶
Mechanisms¶
- Design Pattern Catalog
- A platform team maintains a design pattern catalog for their service architecture, in the tradition of the "Gang of Four."
This sourcePresents the Gang of Four's catalog of recurring object-oriented software design patterns.
- A platform team maintains a design pattern catalog for their service architecture, in the tradition of the "Gang of Four."
- Style Guide or Pattern Library
- This is the same discipline as a design pattern catalog
This sourceCatalogs named recurring design problems, their reusable solution structures and variants, so designers can select established patterns rather than rediscover solutions.
- This is the same discipline as a design pattern catalog
- Technical Bypass or Adapter Design
- The design idea it embodies is the adapter pattern: an intermediary that converts one component's interface into the interface a client expects, letting otherwise-incompatible parts collaborate unchanged.
This sourceDefines the Adapter pattern as converting an existing component interface into the interface a client expects so incompatible components can work together without rewriting the adapted component.
- The design idea it embodies is the adapter pattern: an intermediary that converts one component's interface into the interface a client expects, letting otherwise-incompatible parts collaborate unchanged.
- Undo/Redo Stack Pair
- Its strength is fearless exploration: because every action is reversible and undone actions are preserved for redo, users can experiment freely and step precisely back and forth through their own history.
This sourceDescribes reversible Command objects and a command history that supports arbitrary-level undo and redo.
- Its strength is fearless exploration: because every action is reversible and undone actions are preserved for redo, users can experiment freely and step precisely back and forth through their own history.
Verification¶
Does it exist? Confirmed. This work's ISBN resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Not recorded. Neither this nor any other of the 28 citations of this work carries a recorded support check.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 7 other ways.
- https://www.pearson.com/en-us/subject-catalog/p/design-patterns-elements-of-reusable-object-oriented-software/P200000009480/9780321700698 ×4
- https://books.google.com/books/about/Design_Patterns.html?id=6oHuKQe3TjQC ×2
- https://www.informit.com/store/design-patterns-elements-of-reusable-object-oriented-software-9780201633610 ×2
- https://www.pearson.com/en-us/subject-catalog/p/design-patterns-elements-of-reusable-object-oriented-software/P200000009480 ×2
- https://www.google.com/books/edition/Design_Patterns/6oHuKQe3TjQC ×1
- https://www.informit.com/store/design-patterns-elements-of-reusable-object-oriented-9780201633610 ×1
- https://www.oreilly.com/library/view/design-patterns-elements/0201633612/back.html ×1
Registry ID ref:c6a6f2bf6076 · see in the full table