Community Hub0 Subscribers
Community hub
Design Patterns
View on Wikipediafrom Wikipedia
 | This article may be in need of reorganization to comply with Wikipedia's layout guidelines. (July 2013) |
Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.
Key Information
It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages.[1] The authors are often referred to as the Gang of Four (GoF).[2][3][4][5]
Development and publication history
[edit]The book started at a birds-of-a-feather session at the 1990 OOPSLA meeting, "Towards an Architecture Handbook", where Erich Gamma and Richard Helm met and discovered their common interest. They were later joined by Ralph Johnson and John Vlissides.[6] The book was originally published on 21 October 1994, with a 1995 copyright, and was made available to the public at the 1994 OOPSLA meeting.
Introduction
[edit] | This section may contain an excessive amount of intricate detail that may only interest a particular audience. (October 2020) |
Chapter 1 is a discussion of object-oriented design techniques, based on the authors' experience, which they believe would lead to good object-oriented software design, including:
- "Program to an interface, not an implementation." (Gang of Four 1995:18)
- Composition over inheritance: "Favor 'object composition' over 'class inheritance'." (Gang of Four 1995:20)
The authors claim the following as advantages of interfaces over implementation:
- clients remain unaware of the specific types of objects they use, as long as the object adheres to the interface
- clients remain unaware of the classes that implement these objects; clients only know about the abstract class(es) defining the interface
Use of an interface also leads to dynamic binding and polymorphism, which are central features of object-oriented programming.
The authors refer to inheritance as white-box reuse, with white-box referring to visibility, because the internals of parent classes are often visible to subclasses. In contrast, the authors refer to object composition (in which objects with well-defined interfaces are used dynamically at runtime by objects obtaining references to other objects) as black-box reuse because no internal details of composed objects need be visible in the code using them.
The authors discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (Gang of Four 1995:20). The danger is stated as follows:
- "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)
They warn that the implementation of a subclass can become so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change. Furthermore, they claim that a way to avoid this is to inherit only from abstract classes—but then, they point out that there is minimal code reuse.
Using inheritance is recommended mainly when adding to the functionality of existing components, reusing most of the old code and adding relatively small amounts of new code.
To the authors, 'delegation' is an extreme form of object composition that can always be used to replace inheritance. Delegation involves two objects: a 'sender' passes itself to a 'delegate' to let the delegate refer to the sender. Thus the link between two parts of a system are established only at runtime, not at compile-time. The Callback article has more information about delegation.
The authors also discuss so-called parameterized types, which are also known as generics (Ada, Eiffel, Java, C#, Visual Basic (.NET), and Delphi) or templates (C++). These allow any type to be defined without specifying all the other types it uses—the unspecified types are supplied as 'parameters' at the point of use.
The authors admit that delegation and parameterization are very powerful but add a warning:
- "Dynamic, highly parameterized software is harder to understand and build than more static software." (Gang of Four 1995:21)
The authors further distinguish between 'Aggregation', where one object 'has' or 'is part of' another object (implying that an aggregate object and its owner have identical lifetimes) and acquaintance, where one object merely 'knows of' another object. Sometimes acquaintance is called 'association' or the 'using' relationship. Acquaintance objects may request operations of each other, but they are not responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects, which can often be desirable for maximum maintainability in designs.
The authors employ the term 'toolkit' where others might today use 'class library', as in C# or Java. In their parlance, toolkits are the object-oriented equivalent of subroutine libraries, whereas a 'framework' is a set of cooperating classes that make up a reusable design for a specific class of software. They state that applications are hard to design, toolkits are harder, and frameworks are the hardest to design.
Patterns by type
[edit]Creational
[edit]Creational patterns are ones that create objects, rather than having to instantiate objects directly. This gives the program more flexibility in deciding which objects need to be created for a given case.
- Abstract factory groups object factories that have a common theme.
- Builder constructs complex objects by separating construction and representation.
- Factory method creates objects without specifying the exact class to create.
- Prototype creates objects by cloning an existing object.
- Singleton restricts object creation for a class to only one instance.
Structural
[edit]Structural patterns concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
- Adapter allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
- Bridge decouples an abstraction from its implementation so that the two can vary independently.
- Composite composes zero-or-more similar objects so that they can be manipulated as one object.
- Decorator dynamically adds/overrides behavior in an existing method of an object.
- Facade provides a simplified interface to a large body of code.
- Flyweight reduces the cost of creating and manipulating a large number of similar objects.
- Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity.
Behavioral
[edit]Most behavioral design patterns are specifically concerned with communication between objects.
- Chain of responsibility delegates commands to a chain of processing objects.
- Command creates objects that encapsulate actions and parameters.
- Interpreter implements a specialized language.
- Iterator accesses the elements of an object sequentially without exposing its underlying representation.
- Mediator allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
- Memento provides the ability to restore an object to its previous state (undo).
- Observer is a publish/subscribe pattern, which allows a number of observer objects to see an event.
- State allows an object to alter its behavior when its internal state changes.
- Strategy allows one of a family of algorithms to be selected on-the-fly at runtime.
- Template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
- Visitor separates an algorithm from an object structure by moving the hierarchy of methods into one object.
Reception
[edit]In 2005 the ACM SIGPLAN awarded that year's Programming Languages Achievement Award to the authors, in recognition of the impact of their work "on programming practice and programming language design".[7]
Criticism has been directed at the concept of software design patterns generally, and at Design Patterns specifically. A primary criticism of Design Patterns is that its patterns are simply workarounds for missing features in C++, replacing elegant abstract features with lengthy concrete patterns, essentially becoming a "human compiler". Paul Graham wrote:[8]
When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.
Peter Norvig demonstrates that 16 out of the 23 patterns in Design Patterns are simplified or eliminated by language features in Lisp or Dylan.[9] Related observations were made by Hannemann and Kiczales who implemented several of the 23 design patterns using an aspect-oriented programming language (AspectJ) and showed that code-level dependencies were removed from the implementations of 17 of the 23 design patterns and that aspect-oriented programming could simplify the implementations of design patterns.[10]
In an interview with InformIT in 2009, Erich Gamma stated that the book authors had a discussion in 2005 on how they would have refactored the book and concluded that they would have recategorized some patterns and added a few additional ones, such as extension object/interface, dependency injection, type object, and null object. Gamma wanted to remove the singleton pattern, but there was no consensus among the authors to do so.[11]
See also
[edit]References
[edit]- ^ Zehoo, Edmund (26 January 2010). Zehoo, Edmund (ed.). Pro ODP .NET for Oracle Database 11g. Apress. pp. 351–371. doi:10.1007/978-1-4302-2821-9_13 – via Springer Link.
- ^ Hussain, Shahid; Keung, Jacky; Khan, Arif Ali (2017). "The Effect of Gang-of-Four Design Patterns Usage on Design Quality Attributes". 2017 IEEE International Conference on Software Quality, Reliability and Security (QRS). pp. 263–273. doi:10.1109/QRS.2017.37. ISBN 978-1-5386-0592-9. S2CID 21343926.
- ^ Hunt, John (26 January 2013). Hunt, John (ed.). Scala Design Patterns: Patterns for Practical Reuse and Design. Springer International Publishing. pp. 135–136. doi:10.1007/978-3-319-02192-8_16 – via Springer Link.
- ^ Almadi, Sara H. S.; Hooshyar, Danial; Ahmad, Rodina Binti (26 January 2021). "Bad Smells of Gang of Four Design Patterns: A Decade Systematic Literature Review". Sustainability. 13 (18) 10256. Bibcode:2021Sust...1310256A. doi:10.3390/su131810256.
- ^ Monteiro, Miguel Pessoa; Fernandes, João M. (26 January 2004). Pitfalls of aspectJ implementations of some of the gang-of-four design patterns. Universidad de Extremadura. ISBN 978-84-688-8889-7 – via repositorium.uminho.pt.
- ^ Richard Helm
- ^ "SIGPLAN FY '05 Annual Report" (PDF).
- ^ Graham, Paul (2002). Revenge of the Nerds. Retrieved 11 August 2012.
- ^ Norvig, Peter (1998). Design Patterns in Dynamic Languages.
- ^ Hannemann, Jan (2002). Design pattern implementation in Java and AspectJ.
- ^ Gamma, Erich; Helm, Richard; Johnson, Ralph (22 October 2009). "Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson". InformIT (Interview). Interviewed by Larry O'Brien. Archived from the original on 20 February 2019. Retrieved 1 September 2019.
Design Patterns
View on Grokipediafrom Grokipedia
Historical Development
Publication History
The concept of design patterns in software engineering drew significant inspiration from architect Christopher Alexander's work in the 1970s and 1980s, particularly his 1977 book A Pattern Language: Towns, Buildings, Construction, which described recurring solutions to architectural design problems, and his 1979 book The Timeless Way of Building, which formalized patterns as contextual solutions to common issues.[6][7] In the late 1980s, discussions on adapting these ideas to object-oriented programming began at the annual OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conferences, where researchers identified recurring solutions to software design challenges. A pivotal early milestone occurred in 1987, when Ward Cunningham and Kent Beck presented the paper "Using Pattern Languages for Object-Oriented Programs" at OOPSLA '87, outlining five patterns for Smalltalk graphical user interfaces and envisioning a broader catalog of 100 to 150 patterns for object-oriented systems.[8][9] The collaboration among Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—later known as the "Gang of Four"—emerged during these OOPSLA gatherings in the late 1980s, evolving through informal discussions and shared experiences in developing object-oriented frameworks. Key milestones included the 1990 OOPSLA workshop on pattern languages, which formalized pattern documentation approaches, and subsequent workshops from 1990 to 1993 that refined the ideas through community collaboration.[9] In 1993, the formation of the Hillside Group further supported this effort by promoting pattern research and organizing related events.[10] These efforts culminated in the 1994 publication of the seminal book Design Patterns: Elements of Reusable Object-Oriented Software by Addison-Wesley, authored by the Gang of Four and cataloging 23 reusable patterns for object-oriented design. The book, with ISBN 0-201-63361-2, saw strong initial reception, including over 700 copies sold during its launch event at OOPSLA '94, marking the start of sales that would reach nearly half a million copies over the first 15 years.[11]Key Contributors and Influences
The concept of design patterns in software engineering was primarily shaped by four key contributors known collectively as the "Gang of Four": Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Erich Gamma, a Swiss computer scientist, played a central role in cataloging the patterns, drawing from his PhD thesis on the ET++ application framework at the Union Bank of Switzerland's UBILAB laboratory, where he abstracted reusable design solutions from practical implementations.[12] Richard Helm, a researcher at IBM's T.J. Watson Research Center, initiated the collaboration among the group, emphasizing designs that accommodate change and facilitate refactoring, as seen in his contributions to patterns like Adapter and Bridge.[13] Ralph Johnson provided an academic perspective from his position at the University of Illinois at Urbana-Champaign, where he organized the first Pattern Languages of Programs (PLoP) conference in 1994 to foster systematic pattern documentation and sharing.[14] John Vlissides, the youngest member and a researcher at IBM Watson, contributed insights into pattern application and later expanded on them in works like Pattern Hatching (1996).[15] Their joint efforts culminated in the 1993 ECOOP paper and the influential 1994 book, which formalized 23 core patterns based on collective experiences in object-oriented systems.[12] Intellectual influences on design patterns trace back to architecture, particularly Christopher Alexander's A Pattern Language: Towns, Buildings, Construction (1977), which introduced patterns as named solutions to recurring problems, balancing forces like functionality and aesthetics to create harmonious structures.[16] Alexander's framework for documenting experiential knowledge—through context, problem, and resolution—directly inspired software adaptations, extending object-oriented principles like encapsulation and inheritance to promote reusable, composable designs.[16] In the software domain, Ward Cunningham and Kent Beck advanced this in the 1980s while working with Smalltalk at Tektronix, publishing the first pattern language for object-oriented programs at OOPSLA '87 with five patterns for user interface design, such as Window Per Task and Short Menus.[8] Their work shifted focus from isolated code snippets to interconnected pattern systems, influencing later OOP methodologies by encouraging explicit naming and motivation of design decisions.[8] During the 1980s, object-oriented programming evolved from ad-hoc code reuse—relying on informal copying of structures—to systematic pattern documentation, enabling scalable abstraction and maintenance in complex systems.[17] This transition was facilitated by research at Xerox PARC, where Smalltalk's pure object model provided the foundational environment for experimenting with message-passing and inheritance, directly informing pattern descriptions in the Gang of Four's catalog.[18] University efforts, including Gamma's framework analysis and Johnson's advocacy for pattern workshops at OOPSLA (1991–1992), further promoted collaborative sharing, turning empirical observations into a shared vocabulary for OOP design.[12]Fundamental Principles
Definition and Purpose
Design patterns represent proven, reusable solutions to recurring problems encountered in software design, particularly within object-oriented programming (OOP) paradigms. They provide general templates for structuring code that can be adapted to specific contexts, capturing accumulated experience to address common design challenges without prescribing rigid implementations. Rather than being concrete code snippets, design patterns serve as descriptive frameworks that outline the intent, applicability, structure, and consequences of a solution, enabling developers to communicate and document designs effectively.[19] The primary purpose of design patterns is to enhance software qualities such as flexibility, maintainability, and reusability by mitigating issues like tight coupling between components or inflexible class hierarchies. By encapsulating variations in object creation, composition, and representation, they allow systems to evolve independently in key aspects, promoting loose coupling and modularity. This approach decouples abstractions from their implementations, facilitating easier extension and modification while reducing the need to reinvent solutions for familiar problems.[19][20] These patterns emerged in the 1990s amid the rapid growth of OOP, standardizing best practices to streamline the transition from analysis to implementation in increasingly complex software systems. Their documentation as named, motivated elements fosters a shared vocabulary among designers, aiding learning and collaboration without enforcing a specific methodology.[7][19]Structure of a Design Pattern
The structure of a design pattern follows a standardized template introduced in the seminal work by Gamma et al., which provides a consistent framework for documenting patterns to facilitate communication and reuse among developers.[21] This template is adapted from Christopher Alexander's pattern language for architecture, originally outlined in his 1977 book A Pattern Language, but tailored specifically for software design problems involving object-oriented systems. The template begins with the Pattern Name, a concise and evocative title (often including scope and purpose, such as "Singleton (Creational)") that captures the essence of the pattern and serves as a shared vocabulary in design discussions.[21] It may also include an Also Known As section listing alternative names used in different contexts or languages. Following this, the Intent offers a brief declaration of the pattern's goal, explaining the external quality it achieves and the specific design challenge it resolves, such as decoupling classes to enhance flexibility.[21] Next, the Motivation section illustrates the problem through a concrete scenario, demonstrating why the pattern is necessary and how it addresses recurring issues in object-oriented design without prescribing a unique solution.[21] The Applicability then details conditions under which the pattern is suitable, including situations where it excels (e.g., when direct instantiation leads to tight coupling) and cases where it should be avoided to prevent over-engineering.[21] The Structure depicts the pattern's static organization using class and object diagrams in Object Modeling Technique (OMT) notation—a precursor to UML that visualizes relationships, inheritance, and associations for clarity. Accompanying this, the Participants enumerates the key classes, objects, or roles involved, assigning specific responsibilities to each (e.g., "ConcreteBuilder: constructs and assembles parts to build the objects").[21] The Collaborations describes the dynamic interactions among these participants and any external entities, outlining how they cooperate to accomplish the pattern's objectives.[21] Further, the Consequences analyzes the pattern's implications, weighing benefits like improved modularity against trade-offs such as increased complexity or runtime overhead, emphasizing that patterns introduce flexibility at the cost of added abstraction layers.[21] The Implementation provides practical guidance, including techniques to avoid common pitfalls, language-specific considerations (e.g., in C++ or Smalltalk), and optimization tips.[21] A Sample Code segment follows with pseudocode or snippets demonstrating the pattern in action, often in an object-oriented language to highlight key mechanisms.[21] To ground the pattern in practice, the Known Uses cites at least two real-world examples from diverse systems, such as libraries or applications, showing its proven application without exhaustive listings.[21] Finally, Related Patterns references other patterns that complement, refine, or contrast with it, suggesting combinations or distinctions to guide broader design choices.[21] While this template ensures uniformity across the 23 patterns cataloged by Gamma et al., it is not rigidly enforced in all documentation; its consistent application in their book promotes accessibility and comparability, allowing developers to focus on conceptual trade-offs like balancing simplicity with extensibility.Pattern Classification
Creational Patterns
Creational patterns abstract the object creation process in object-oriented systems, allowing developers to defer instantiation decisions to subclasses or runtime configurations rather than hard-coding specific classes. This abstraction promotes flexibility, making code more reusable and independent of concrete object types, while encapsulating creation logic to support varying system requirements without altering client code. By focusing on instantiation mechanisms, these patterns address how objects are created, composed, and represented, often introducing indirection to enable runtime variations.[12] The seminal classification by the Gang of Four (GoF) identifies five core creational patterns: Abstract Factory, Builder, Factory Method, Prototype, and Singleton. These patterns originated from efforts to catalog reusable solutions in object-oriented design, drawing from experiences in frameworks like Smalltalk and C++ applications. They are particularly useful in scenarios where object creation needs to be configurable, such as in GUI toolkits or database systems, where the exact types of objects may vary based on context or user input.[12] Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes, ensuring that the system produces compatible object sets. A client uses the abstract factory to create products, with concrete factories implementing the interface to instantiate specific variants, thus isolating creation from product details. This pattern is ideal for systems requiring interchangeable product families, such as user interface toolkits that generate widgets for different platforms (e.g., Motif or Open Look scrollbars) based on runtime selection. It trades direct class references for a higher level of abstraction, reducing dependencies but potentially increasing the number of classes needed.[12] Builder separates the construction of a complex object from its representation, allowing the same construction process to create different representations. It defines a director to oversee the building steps via a builder interface, where concrete builders handle the incremental assembly of parts into the final product. This pattern suits scenarios involving stepwise object creation with optional components, like parsing rich text format (RTF) documents into ASCII, TeX, or other formats using a shared builder process. By encapsulating construction logic, Builder avoids telescoping constructors in client code but introduces additional objects for the building process.[12] Factory Method defines an interface for creating an object but lets subclasses decide which class to instantiate, thereby deferring instantiation to subclasses. In a typical structure, a creator class declares the factory method, which concrete subclasses override to return specific products, allowing the creator to operate on abstract product interfaces. Commonly applied in frameworks like application classes that create documents (e.g., viacreateDocument() in a drawing program), this pattern enables extension without modifying the base class, as seen in Java's java.awt.Component.createImage() for platform-specific images. It promotes loose coupling but requires subclassing for each variant, adding to the class hierarchy.[12]
Prototype specifies the kinds of objects to create using a prototypical instance and creates new objects by cloning this prototype, avoiding the need for subclasses to specify creation details. Objects implement a clone operation, often through an interface like Java's Cloneable, allowing clients to customize instances at runtime by copying and modifying prototypes. This is beneficial in systems with a large number of similar objects, such as a drawing editor cloning line or shape prototypes for efficiency over repeated constructors. Prototype reduces subclass proliferation compared to Factory Method but may incur runtime overhead from deep copies in complex objects.[12][1]
Singleton ensures a class has only one instance and provides a global point of access to it, controlling object multiplicity through a private constructor and a static instance method. Concrete implementations often use lazy initialization or eager loading to manage the single instance, preventing multiple creations via checks or locks. It is commonly used for resources like database connections or configuration managers where shared access is essential, as in Java examples enforcing one connection object across an application. While Singleton simplifies global access, it can introduce tight coupling and testing challenges due to hidden dependencies.[22][1]
Overall, creational patterns introduce abstraction layers that defer creation decisions, enhancing modularity in evolving systems like GUI frameworks where Factory Method allows subclass-defined widgets. However, they often impose trade-offs, such as added runtime overhead from indirection or increased complexity in managing factories and prototypes, balanced against gains in flexibility and maintainability.[12]
Structural Patterns
Structural design patterns focus on simplifying the relationships between entities in object-oriented systems by providing ways to compose classes and objects into larger structures while keeping them flexible and efficient. These patterns emphasize the use of inheritance and composition to form hierarchies that minimize dependencies between components, allowing for easier maintenance and extension of software. According to the seminal work by Gamma et al., there are seven structural patterns: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, and Proxy, which collectively address challenges in interface compatibility, abstraction-implementation decoupling, and resource management.[23][24] The Adapter pattern converts the interface of a class into another interface that clients expect, enabling compatibility between otherwise incompatible systems without modifying the original classes. It acts as a wrapper that delegates requests to the adaptee, promoting loose coupling and reuse of existing code. A key concept is the use of object composition over inheritance to adapt interfaces dynamically. For instance, in a scenario where a Turkey object needs to behave like a Duck, an Adapter class implements the Duck interface and delegates calls to the Turkey. This pattern is particularly useful in integrating legacy code with modern systems.[23][24] The Bridge pattern decouples an abstraction from its implementation, allowing the two to vary independently and preventing a proliferation of subclasses that would result from tight coupling. It achieves this through a bridge interface that connects abstract classes to concrete implementations, enabling runtime selection of implementations. This pattern balances flexibility with added complexity, often employing interfaces to abstract operations. An example is separating the shape-drawing abstraction (e.g., circles, squares) from rendering APIs (e.g., OpenGL or DirectX), allowing shapes to work with multiple graphics backends without subclass explosion.[23][24] The Composite pattern composes objects into tree structures to represent part-whole hierarchies, treating individual objects and compositions uniformly through a common interface. This enables clients to interact with complex structures as if they were simple objects, using recursion for operations on the hierarchy. Key concepts include leaf and composite components sharing the same interface, which simplifies client code but requires careful handling of structural integrity. It is commonly applied in graphical user interfaces, such as menu systems where menus contain submenus and items.[23][25] The Decorator pattern attaches additional responsibilities to an object dynamically, providing a flexible alternative to subclassing for extending functionality. It uses a decorator wrapper that conforms to the same interface as the component it enhances, allowing multiple decorators to be stacked. This pattern supports the open-closed principle by keeping classes open for extension but closed for modification, relying on delegation and composition. A classic example is enhancing a base Beverage class with condiments like Mocha or Whip at runtime, each adding cost and description without altering the core class.[23][24] The Facade pattern provides a unified, simplified interface to a complex subsystem, hiding its intricacies from clients and making it easier to use. It defines a high-level entry point that delegates to subsystem components, adhering to the principle of least knowledge to reduce dependencies. This promotes subsystem independence and eases integration. For example, a HomeTheaterFacade can orchestrate popcorn popper, projector, and amplifier operations into a single "watchMovie" method, simplifying the control of home entertainment systems.[23][24] The Flyweight pattern minimizes memory usage by sharing as much data as possible among similar objects, treating fine-grained objects efficiently through intrinsic (shared) and extrinsic (context-specific) state. It uses a factory to manage a pool of reusable flyweight instances, centralizing immutable state. This pattern balances performance gains in resource-constrained environments with the overhead of state management. In graphics applications, such as word processors, it shares glyph representations for characters across documents, significantly reducing memory for repeated fonts and symbols.[23][24][26] The **Proxy** pattern provides a surrogate or placeholder for another object to control access to it, such as for lazy loading, access protection, or remote execution. The proxy implements the same interface as the real subject and forwards requests while adding custom behavior. It enhances flexibility by allowing indirect access without exposing the subject directly. Common in scenarios like image loading, where a proxy loads a high-resolution image only when needed, deferring costly operations.[23][25] Overall, structural patterns prioritize interfaces over concrete classes to foster loose coupling and composition over inheritance, enabling scalable object hierarchies that adapt to changing requirements while optimizing performance.[23][24]Behavioral Patterns
Behavioral patterns in software design focus on the efficient communication and assignment of responsibilities among objects, emphasizing dynamic interactions at runtime rather than static structure. These patterns enable objects to collaborate flexibly while minimizing direct dependencies, thereby promoting loose coupling and enhancing system maintainability. In their foundational book, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (collectively known as the Gang of Four or GoF) cataloged 11 behavioral patterns, which address how objects exchange information and manage behavior without tightly binding sender and receiver.[23] A core advantage of behavioral patterns is their emphasis on runtime dynamics, such as delegating requests or notifying dependents of changes, which contrasts with more static concerns like class composition. For instance, the Observer pattern is commonly applied in event-driven systems, such as graphical user interfaces (GUIs), where a subject object notifies multiple observers of state changes without explicit coupling.[23] While these patterns foster modularity and extensibility, they often introduce layers of indirection, potentially increasing complexity and overhead in performance-critical applications.[23] The following outlines the 11 behavioral patterns from the GoF, highlighting their purpose, key mechanisms, and consequences:- Chain of Responsibility: This pattern allows a request to pass along a chain of handlers until one processes it, decoupling the sender from the receiver and enabling dynamic handler assignment. It is applicable when the handler is not predetermined or when unhandled requests are tolerable; consequences include flexibility but risk of unprocessed requests. Handlers form a linked structure, often using a successor reference for delegation.[23][27]
- Command: Encapsulates a request as an object, permitting parameterization, queuing, logging, or undoing of operations. It suits scenarios like transaction systems or macro recording; benefits include decoupling the invoker from the receiver and supporting undo functionality, though it may proliferate small classes. The structure involves a Command interface with an execute method, invoked by a client on a receiver.[23][27]
- Interpreter: Defines a representation for a language's grammar and provides an interpreter to process sentences in that language, ideal for simple grammars like command queries. It uses abstract and terminal expressions in a syntax tree; advantages include easy rule extension, but complexity grows for intricate languages. Known uses include parsing in text adventure games.[23][27]
- Iterator: Provides sequential access to elements of an aggregate object without exposing its underlying representation, supporting multiple traversal strategies. Applicable for collections needing uniform iteration; it abstracts traversal via next() operations, simplifying client code while supporting polymorphism across aggregates. Consequences involve hiding internal details but potential inefficiency in some implementations.[23][27]
- Mediator: Centralizes complex communications and control among a set of objects, reducing dependencies by routing interactions through a mediator. It fits tangled object graphs with defined protocols; benefits include loose coupling and simplified individual objects, though the mediator can become a bottleneck. Colleagues communicate solely via the mediator.[23][27]
- Memento: Captures and externalizes an object's internal state without violating encapsulation, enabling later restoration for features like undo. Suitable for state-saving in editors; the structure involves an originator creating a memento, managed by a caretaker. It preserves privacy but may consume significant memory for large states.[23][27]
- Observer: Defines a one-to-many dependency where subjects notify observers of state changes, allowing loose coupling in publish-subscribe scenarios. It applies to event systems or model-view architectures; the subject maintains observer lists and broadcasts updates, promoting abstraction but risking cascading notifications. Widely used in GUI frameworks for event handling.[23][27]
- State: Permits an object to alter its behavior when its internal state changes, appearing as if the class changed, by delegating to state-specific objects. Useful for avoiding conditional logic in state-dependent behaviors, like TCP connections; consequences include clear transitions but potential proliferation of states. The context delegates to concrete state implementations.[23][27]
- Strategy: Defines a family of interchangeable algorithms, encapsulating each to allow runtime selection and variation. It suits contexts with algorithm variants, like sorting methods; the context delegates to a strategy interface, enabling flexibility but adding objects. Related to state management in dynamic behaviors.[23][27]
- Template Method: Specifies the skeleton of an algorithm in a method, deferring specific steps to subclasses while keeping the structure invariant. Applicable for frameworks with customizable steps, like data processing pipelines; it promotes code reuse via inheritance but limits subclass flexibility. The abstract class defines the template method invoking primitive operations.[23][27]
- Visitor: Represents an operation to be performed on elements of an object structure, allowing new operations without altering element classes, by separating algorithms from structure. It fits stable hierarchies needing varied traversals, like syntax trees; visitors define visit methods per element type, with elements accepting visitors. Consequences include adding operations easily but complicating structure changes. Used in compilers for type-checking or code generation.[23][28]