GoF (Gang of Four) behavioral patterns are concerned with the algorithms of objects and the assignment of responsibilities among objects. These patterns also address communication between these objects and represent the interconnection between the objects themselves. This interconnection can include inheritance and the performance of tasks.
The table below describes each of the GoF behavioral patterns:
Pattern Name | Design Problem Handled | Role | Description |
---|---|---|---|
Chain of Responsibility | By giving more than one object a chance to handle a request, you can avoid coupling the sender of that request to its receiver. The receiving objects are chained and the request is passed along that chain until an object handles it. | Handler | Defines an abstract interface used for specific requests |
ConcreteHandler | Implements the operations declared in the Handler interface | ||
Client | Initiates communication via a Concrete Handle | ||
Command Pattern | You can parameterize clients with different requests by encapsulating a request as an object. You can also queue or log requests, and support undoable operations. | Command | Defines an abstract interface for operation execution. |
ConcreteCommand | Implements the operations declared in the Command interface. | ||
Client | Creates a ConcreteCommand object | ||
Invoker | Executes the interface defined on the Command derived object | ||
Receive | Performs the concrete implementation for the requested operation | ||
Interpreter | Defines a representation for a given language's grammar. An interpreter uses the representation to interpret sentences in the language. | AbstractExpression | Defines an abstract interpret operation that must be implemented by all nodes in the abstract syntax tree |
TerminalExpression | Provides a concrete implementation of the interpret operation specifically associated with terminal symbols in the grammar. | ||
NonterminalExpression | Provides a concrete implementation of the interpret operation specifically associated with nonterminal symbols in the grammar | ||
Iterator | Provides a uniform mechanism for navigating disparate Elements in a collection without exposing specific implementation details of the Element being navigated. | Iterator | Defines an abstract interface used to navigate Elements. |
ConcreteIterator | Implements the operations declared in the Iterator interface | ||
Aggregate | Defines an abstract interface used to create a ConcreteIterator object. | ||
ConcreteAggregate | Implements the operations declared in the Aggregate interface. | ||
Mediator | Provides a uniform mechanism for navigating disparate Elements in a collection without exposing specific implementation details of the Element being navigated. | Iterator | Defines an abstract interface used to navigate Elements. |
Concrete Iterator | Implements the operations declared in the Iterator interface | ||
Aggregate | Defines an abstract interface used to create a ConcreteIterator object | ||
Concrete Aggregate | Implements the operations declared in the Aggregate interface | ||
Memento | An object's internal state can be captured and externalized so that the object can be restored to this state later. This is done without violating encapsulation. | Memento | An object that manages the state of the Originator at a given point in time. |
Originator | Creates a Memento object providing it the necessary state information in the current context. | ||
Caretaker | Aggregates Memento objects. | ||
Observer | A one-to-many dependency is defined between objects. When one object changes state, all its dependents are automatically notified and updated. | Subject | Defines an abstract interface used to attach various Observers to this Subject. |
Observer | Defines an abstract interface used when a Subject the Observer is observing is updating. | ||
ConcreteSubject | Implements the operations declared in the Subject interface. | ||
ConcreteObserver | Implements the operations declared in the Observer interface. | ||
State | Provides a mechanism that allows an object to alter its behavior when internal state changes occur. | Context | Defines the interface used by clients to gain access to the Context's state. |
State | Defines an abstract interface that must be implemented by ConcreteState. The interface is domain specific | ||
ConcreteState | Implements the operations declared in the State interface | ||
Strategy | A family of algorithms is defined, each one is encapsulated, and each one can be interchangeable. The algorithm can vary independently from clients that use it. | Strategy | Defines an abstract interface implemented by ConcreteStrategy objects |
ConcreteStrategy | Implements the operations declared in the Strategy interface. | ||
Context | Aggregates objects that implement the Strategy interface | ||
TemplateMethod | The skeleton of an algorithm is defined in an operation, and some steps are deferred to subclasses. Without changing the algorithm's structure, subclasses can redefine certain steps of an algorithm. | AbstractClass | Defines the various operations that can be overridden by the ConcreteClass. |
ConcreteClass | Implements the specific operations defined in AbstractClass. | ||
Visitor | Visitor represents an operation that is to be performed on the Elements of an object structure. You can define a new operation without changing the classes of the Elements on which it operates. | Visitor | Provides operations specific to concrete Elements that allow this visitor object to visit them. |
ConcreteVisitor | Implements the operations declared in the Visitor interface. | ||
Element | Declares an Accept operation that allows Visitor objects to process the current Element. | ||
ConcreteElement | Implements the operations declared in the Element interface. | ||
ObjectStructure | Manages the collaboration between ConcreteVisitor and ConcreteElement objects. |