SADP MODULE –03

1. CHAIN OF RESPONSIBILITY.

Motivation
The Chain of Responsibility pattern helps decouple the sender of a request from its receivers by giving multiple
objects a chance to handle the request. The request is passed along a chain of objects until one of them handles
it.
A practical example is a context-sensitive help system in a graphical user interface. If a user clicks on a "Help"
button in a dialog box, the request for help may travel up a chain (e.g., Button → Dialog Box → Application)
until the appropriate help information is found.

Applicability
Use the Chain of Responsibility pattern when:
1. More than one object may handle a request, but the exact handler is not known at compile time.
2. You want to avoid explicitly specifying the receiver of a request in the client.
3. The set of objects that can handle a request should be determined dynamically.

Implementation

1. Successor Chain:
a. Define the chain of objects through which requests are passed. This can be done using:
i. New links specifically created for this chain.
ii. Existing relationships (e.g., parent references in a hierarchy).
2. Request Handling:
a. Each object in the chain shares a common interface for handling requests.
b. If the current object cannot handle the request, it forwards it to the next object in the chain.
3. Request Representation:
a. Simple: Hardcoded request handling logic in each object.
b. Advanced: Use a generic handler function and conditionally dispatch requests based on
parameters or request codes.
4. Forwarding: Objects can handle requests directly or forward them to their successor using the default
logic provided by the base class.

Participants

1. Handler (e.g., HelpHandler):

Structure:
2. ITERATOR

Motivation
The Iterator pattern provides a way to access elements of an aggregate object sequentially without exposing its
underlying representation. This is particularly useful when working with collections or data structures, allowing
traversal without binding to their internal implementation.
For example, in a List class, you may need to iterate over elements without exposing internal details like the
storage mechanism. The Iterator object takes responsibility for maintaining the traversal state, including the
current element and progress.

Applicability
The Iterator pattern is applicable when:
1. You need to traverse elements of an aggregate object without exposing its internal structure.
2. Multiple traversal methods or algorithms are required for the same aggregate structure.
3. A uniform traversal interface is needed for different types of aggregate structures.

Implementation

1. Iterator Interface: Defines methods like First, Next, IsDone, and CurrentItem for traversal operations.
2. Concrete Iterator: Implements the traversal logic specific to an aggregate structure and tracks the
current position during iteration.
3. Aggregate Interface: Defines an operation, such as CreateIterator, to return an instance of the iterator.
4. Concrete Aggregate: Implements the CreateIterator operation to provide the appropriate
ConcreteIterator.

Additional Considerations:

• Control of Iteration:
o External Iterators: The client explicitly controls the traversal.
o Internal Iterators: The iterator defines the traversal logic.
• Robust Iterators: Handle modifications to the collection (e.g., additions or deletions) without errors
during traversal.
 • Polymorphism: Use an abstract base class for iterators to enable different implementations for various
aggregate types.

Participants
1. Iterator: Defines the interface for accessing and traversing elements.
2. ConcreteIterator: Implements the Iterator interface and keeps track of the current traversal state.
3. Aggregate: Defines the interface for creating an iterator.
4. ConcreteAggregate: Implements the interface to create a specific ConcreteIterator for its structure.
Structure

3. MEDIATOR

Motivation
The Mediator pattern is used to reduce the complexity of communication between multiple objects by
centralizing their interactions through a mediator object. Instead of objects referring to and communicating
directly with one another, they communicate via a mediator, which promotes loose coupling.
For example, in a dialog box in a graphical user interface (GUI), multiple widgets such as buttons, text fields,
and drop-down menus interact. Dependencies among widgets can lead to a tightly coupled design, making the
system harder to maintain. Using a mediator allows these widgets to coordinate their behavior through a central
controller, decoupling them and simplifying maintenance.
Applicability
Use the Mediator pattern when:
1. A set of objects communicates in well-defined but complex ways, leading to tangled and hard-to-
maintain interactions.
2. Reusing an object is difficult because it interacts with numerous others.
3. Behavior distributed among several classes should be centralized for better control and customizability.

Implementation

1. Define the Mediator Interface: The mediator interface declares methods for communication between
colleague objects.
2. Concrete Mediator: Implements the mediator interface and coordinates communication between
colleague objects. It holds references to these colleagues and implements the interaction logic.
3. Colleague Objects:
a. Objects participating in communication through the mediator. They interact with one another via
the mediator, not directly.
 b. Each colleague maintains a reference to the mediator.
Participants

1. Mediator: Defines an interface for communication between colleague objects (e.g., DialogDirector).
2. ConcreteMediator: Implements the mediator interface and coordinates interaction between colleagues
(e.g., FontDialogDirector).
3. Colleague Classes:
a. Individual objects that communicate via the mediator (e.g., ListBox, EntryField).
b. Each colleague is aware of the mediator and communicates changes to it.
4. Client: Creates colleague objects and connects them to the mediator.

Benefits
1. Reduces Dependencies: Simplifies the object relationships by eliminating direct dependencies.
2. Centralized Control: Centralizes how objects interact, making it easier to maintain and modify
interaction logic.
3. Promotes Reusability: Objects become more reusable as they are decoupled from other objects.

Structure

4. COMMAND

Motivation
The Command pattern encapsulates a request as an object, enabling parameterization of clients with different
requests, queuing or logging requests, and supporting undoable operations. This pattern decouples the object
making the request from the one executing it.
For example, user interface toolkits often include buttons or menu items that execute specific actions. Since
these toolkits don't know the details of application-specific actions, the Command pattern helps bridge this gap
by encapsulating requests as objects.

Applicability
Use the Command pattern when you need to:
1. Parameterize objects with operations.
2. Specify, queue, or execute requests at varying times.
3. Implement undoable operations by maintaining the necessary state in the command.
4. Support logging changes so operations can be tracked or repeated.
5. Structure a system with high-level operations, such as transactions or task scheduling.
Implementation
1. Command Interface: Define a common interface for all commands with an execute method.
2. Concrete Command Classes:
a. Bind a receiver (the object that performs the action) with an action.
b. Implement the execute method to invoke the action on the receiver.
3. Invoker:
a. Maintains a reference to a Command object.
b. Invokes the command’s execute method, which triggers the associated action.
4. Receiver: Contains the logic for the action to be performed.
5. Client: Creates specific Command objects, assigning the appropriate receiver and action.

Participants
1. Command: Declares an interface for executing an operation.
2. ConcreteCommand (e.g., PasteCommand, OpenCommand):
a. Implements the Command interface.
b. Defines the link between a Receiver and the action.
3. Invoker (e.g., MenuItem): Requests the Command to execute the operation.
4. Receiver (e.g., Document, Application): Knows how to perform the operations associated with a
request.
5. Client: Configures the commands by associating receivers and actions.
Structure

5. Interpreter

Motivation
The Interpreter design pattern is used to define a grammar for a language and provide an interpreter that can
process sentences in that language. It is particularly useful when a recurring problem can be expressed as
instances of a domain-specific language (DSL). The pattern helps solve such problems by interpreting sentences
using a predefined structure and operations.
For example, consider regular expressions, which are used to search for patterns in strings. Instead of
implementing a custom algorithm for every pattern, an interpreter for the regular expression language can be
created, enabling a more reusable and flexible solution.

Applicability
The Interpreter pattern is applicable when:
1. A language needs interpretation, and its grammar can be represented using abstract syntax trees (ASTs).
 2. The grammar of the language is simple, avoiding complexities that make maintenance difficult.
3. Performance efficiency is not a primary concern.
4. You need to solve similar problems repeatedly and require a structured language for this purpose.

Participants

1. AbstractExpression (e.g., RegularExpression): Defines the interface for the Interpret operation.
2. TerminalExpression (e.g., LiteralExpression): Implements the Interpret operation for terminal symbols
in the grammar.
3. NonterminalExpression (e.g., AlternationExpression, RepetitionExpression)
a. Implements the Interpret operation for non-terminal grammar rules.
b. Maintains references to subexpressions (e.g., for R ::= R1 R2 ... Rn, it holds references to R1,
R2, ..., Rn).
4. Context: Holds global information used during interpretation, such as the input string and the current
matching state.
5. Client
a. Constructs or uses an AST representing a sentence in the language.
b. Initiates the interpretation by calling the Interpret method.
Structure