Design Patterns

Gamma, E., Helm, Johnson, & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Type

Book chapter

Intellectual base

Textbook

Year

1994

ISBN

9780201633610

Link

https://www.oreilly.com/library/view/design-patterns-elements/0201633612/

Cited from

architecture_urban_planning, art_aesthetics, cognitive_science, computer_science, earth_sciences, engineering_design, mathematics, neuroscience, organizational_management, philosophy, philosophy_logic, psychology, sociology_anthropology, systems_engineering

Cited by

26 citations across 25 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes

• Abstraction

  • This source(Tier C — bibliography only; existence verified.) The 23 'Gang of Four' reusable object-oriented design patterns. Link-only.

• 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).

• Boundary

  • This sourceBibliography-only (Tier C).

• 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.

• Compatibility
  • This is compatibility via adaptation, not inherent interchangeability—the structural pattern Gamma, Helm, Johnson, and Vlissides (1994) formalize in the Adapter and Bridge design patterns.
• Decomposition

  • This sourceBibliography-only (tier C). Verified.

• Dependency

  • This sourceCatalog of 23 patterns; several (e.g., Dependency Inversion via abstractions, Observer) manage object dependencies. (Bibliography-only.)

• Design Patterns

  • This sourceThe 'Gang of Four' book; establishes 23 canonical OO patterns and adapts Alexander's methodology to software.

• 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.

• 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.

• 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
  • The encapsulation of design decisions and data structures such that alternative implementations can be substituted without breaking dependent modules
• 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.

• 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.

• 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.

• 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.

• 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.

• Viewpoint
  • Dashboards and software. A finance dashboard and a frontline operations dashboard expose different access sets and structurally hide different things; observer-pattern subscribers each see only the state changes their subscription exposes.

Domain-specific

• Proxy Pattern
  • The GoF formulation calls the proxy a surrogate or placeholder that controls access to another object.

Mechanisms

• Design Pattern Catalog
  • 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.

Verification

This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 6 other ways.

• https://www.pearson.com/en-us/subject-catalog/p/design-patterns-elements-of-reusable-object-oriented-software/P200000009480/9780321700698 ×3
• https://books.google.com/books/about/Design_Patterns.html?id=6oHuKQe3TjQC ×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