Software Architecture and

Design pattern
18CS731
 Behavioral Patterns

➢Behavioral patterns are concerned with algorithms and the assignment

of responsibilities between objects.

➢Behavioral pattens describes not just patterns of objects or classes but

also the pattern of communication between them.

➢Behavioral class patterns use inheritance to distribute behavior

between classes.
 Different types of behavioral patterns
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Template Method
 Chain of Responsibility
➢Intent : Avoid coupling the sender of a request to its receiver by giving
more than one object a chance to handle the request.

➢Motivation : To organize help information according to its generality from

the most specific to the most general. Furthermore, it’s clear that a help
request is handled by one of several user interface objects.

➢Applicability : When more than one object may handle the request, and the
handler isn’t known a priori.
• When you want to issue a request to one of several objects without
specifying the receiver explicitly.
➢Structure :
➢Participants :
• Client : Initiates the request to the concrete handler object on the chain.
• Handler (help handler) : Defines the interface for handling requests and
implements the successor link.
• Concrete Handler (Print button) : It handler the request it is responsible for
and can access its successors.

➢Collaborations : When a client issues a request, the request propagates

along the chain until a concrete handler object takes responsibility for
handling it.

➢Consequences : Reduced coupling, Added flexibility in assigning

responsibilities to objects, Receipt isn’t guarented.
➢Implementation : There are 4 implementation issues to consider
1. Implementing the successor chain 2. Connecting successor
3. Representing request 4.Automatic forwarding in small talk.

➢Known uses : MacApp and ET++ event handler.

➢Related patterns : Chain of responsibility is often applies in conjunction with

composite. There, a component parent can act as its successor.
 Command
➢Intent : Encapsulates a request as an object , thereby letting you
parameterize clients with different request , queue or log request , and
support undoable operations.

➢Also Known as : Action, Transaction.

➢Motivation :
➢Applicability : Commands are an object-oriented replacement for callback.
• Specify, queue and execute request at different times.
• It support undo operation.

➢Structure :
➢Participants :
• Client : Creates a concrete command object and sets its receiver.
• Receiver (Application) : Know how to perform the operation associated
with carrying out a request.
• Concrete command (open command) : Defines a binding between object
and an action.
• Command : Declares an interface for executing an operation.
• Invoker (Menu Item) : Asks the command to carry out the request.

➢ Collaboration : The client creates a concrete command object and specify its
receiver and then invoker object stores the concrete command object . The
invoker issues the request by calling execute on the command and concrete
command object invokes operation on ite receiver to carry out the request.
➢Consequences : Command decouple the objects that invokes the operation from
the one that knows how to perform it.
• Commands are first class objects.
• It’s easy to add new commands, because you don’t have to change existing
classes.

➢Implementation : Here , we have 4 issues. 1. How intelligent a command

should be. 2.Supporting undo and redo. 3. Avoiding error accumulation in the
udo process. 4. Using c++ template.

➢Known uses : MacApp, ET++ Unidraw and Interviews.

➢Related Patterns : A command can be used to implement Macro command

 Interpreter
➢Intent : Given a language, defines a representations for its grammar along with
an interpreter that uses the representation to interpret sentences in the
language.

➢Motivation : If a particular kind of problem occurs often enough, then it might

be worthwhile to express instance of the problem as sentences in a simple
language.

➢Applicability : The interpreter pattern works best when the grammar is simple.
• Efficiency is not critical concerns.
➢Structure :
➢Participants : Client : Invokes the Interpreter operations.
• Abstract Expression (Regular Expression) : Declares an abstract interpret
operation that is common to all nodes in the abstract syntax tree.
• Terminal Expression (Literal Expression) : Implements an interpret
operation associated with terminal symbols in the grammar.
• Non Terminal Expression (Alternation Expression) : Implements an
interpret operation for nonterminal symbols in the grammar.
• Context : Contains information that’s global to the interpreter.

➢Collaboration : The client builds the sentences as an abstract syntax tree of

nonterminal expression and terminal expression. Then the client initializes the
context and invokes the interpret operation.

➢Implementation : There are 3 issues in Interpreter.

1. Creating the abstract syntax tree. 2. Defining the interpret operation.
3. Sharing terminal symbols with the flyweight pattern.
➢Implementation : There are 3 issues in Interpreter. 1. Creating the abstract
syntax tree. 2. Defining the interpret operation. 3. Sharing terminal symbols
with the flyweight pattern.

➢Known uses : Small Talk compliers.

➢Related patterns : The related patterns to the interpreter are Composite,

Flyweight and Iterator.
 Iterator
➢Intent : Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.

➢Also known as : Cursor

➢Motivation : An aggregate object such as a list should give you a way to

access its elements without exposing its internal structure.
➢Applicability : To access an aggregate object contents without exposing its
internal representation .
• To support multiple traversal of aggregate objects.

➢Structure :
➢Participants :
• Aggregate : Defines an interface for creating an iterator object.
• Iterator : Defines an interface for accessing and traversing elements.
• Concrete Iterator : Implements the iterator interface.
• Concrete Aggregate : Implements the iterator creation interface to return
an instance of the proper concrete iterator.

➢Collaboration : A concrete iterator keeps track of the current object in the

aggregate and can compare the succeeding object in the traversal.

➢Consequences : The iterator pattern has three important consequences.

• It support variation in the traversal of an aggregate.
• Iterators simplify the aggregate interface.
• More than one traversal can be pending on an aggregate.
➢Implementation : It has total 8 issues.
1.Who controls the iteration. 2.Who defines the traversal algorithm.
3.How robust is the iterator. 4.Additional iterator operations. 5.Using
polymorphic iterator in C++. 6.Iterator may have privileged access.
7.Iterator for composite. 8.Null iterator.

➢Known uses : Small Talks.

➢Related patterns : The related patterns to the iterator are Composite, Factory
method and memento.
 Mediator
➢Intent : Defines an object that encapsulates how a set of objects interact.

➢Motivation : It can be difficult to change the system’s behavior in any

significant way, since behavior is distributed among many objects. As a
result, you may be forced to define many subclasses to customize the
system behavior.

➢Applicability : Reusing an object is difficult because it refers to and

communicates with many other objects.
➢Structure :
➢Participants : Mediator (Dialog Director) : Defines an interface for
communicating with colleague objects.
• Colleague classes (List Box) : Each colleague communicates with is
mediator whenever it would have otherwise communicated with another
colleague.
• Concrete Mediator (Front Dialog Director) : Implements co-operative
behaviour by co-ordinating colleague objects.

➢Collaborations : Colleague send and receive requests from a mediator object.

The mediator implements the co-operative behaviour by routing request
between the appropriate colleague.

➢Consequences : It limits scheduling, decouples colleagues, simplifies object

protocols, it abstract how objects co-operate and centralize controls.
➢Implementation : There are 2 issues in mediator.
1.Omitting the abstract mediator class. 2.Colleague mediator communication.

➢Known uses : ET++ and Small Talk.

➢Related pattern : Façade differs from mediator in that it abstract a subsystem

of objects to provide a more convenient interface.
• Colleague can communicate with the mediator using the observer pattern.
 Memento
➢Intent : Without violating encapsulation, capture and externalize an object
internal state so that the object can be restored to this state later.

➢Also known as : Token

➢Motivation : Sometimes, it’s necessary to record the internal state of an

object. This is requires when implementing checkpoints and undo
mechanism that let users back out tentative operation or recover from errors.
➢Applicability : A snapshot of an objects state must be saved so that it can be
restored to that state later.
• A direct interface to obtaining the state would expose implementation details
and break the objects encapsulation.

➢Structure :
➢Participants : Originator (Constraint Solver) : Creates a memento containing a
snapshots of its current internal state.
• Memento (Solver state) : Stores internal state of the originator object
• Caretaker (Undo mechanism) : It is responsible for the memento’s
safekeeping.

➢Collaborations : A caretaker request a memento from an originator, holds it for a

time, and passes it back to the originator.

➢Consequences : Preserving encapsulation boundaries, it simplifies originator,

using mementos might be expensive, and defining narrow and wide interfaces.
➢Implementation : The memento has 2 issues.
1.Language support. 2.Storing incremental changes.

➢Known uses : C++ and C solver class.

➢Related patterns : Commands can use memento to maintain state for undoable
operations.
• Memento’s can be used for iteration as described earlier.
 Observer
➢Intent : Defines a one-to-many dependency between objects so that when
one object changes state, all its dependents are notified and updated
automatically.

➢Also known as : Dependents, Publish-Subscribe.

➢Motivation : A common side effect of partitioning a system into a collection

of co-operating classes is the need to maintain consistency between related
objects.
➢Applicability : When an abstraction has two aspects, one dependent on the other.
• When a change to one object requires changing others.

➢Structure :
➢Participants :
• Subject : Knowns its observer. Any number of observer objects may observe
a subject.
• Observer : Defines a updating interface for objects that should be notified of
changes in a objects.
• Concrete Subject : Store state of interest to concrete observer objects.
• Concrete observer : It maintains a references to a concrete subject objects.

➢ Collaboration : Concrete subject notifies its observer whenever a change

occurs that could make its observer state inconsistent with its own.

➢Consequences : Abstract coupling between subject, observer and support for

broadcast communication and unexpected updates.
➢Implementation : Totally , it has 5 issues.
1. Mapping subjects to their observer. 2.Observing more than one subject
3. Who triggers the update. 4.Dangling references to delete subjects.
5. Making sure subjects state is self consistent before notification.

➢Known uses : Small talk Model/View/Controller (MVC), ET++.

➢Related patterns : Mediator and singleton are the related pattern for observer.
 State
➢Intent : Allow an object to alter its behavior when its internal state changes.

➢Also known as : Objects for state.

➢Motivation : When a TCP Connection object receives requests from other

objects, it responds differently depending on its current state. The key idea
in this pattern is to introduce an abstract class called TCP State to represent
the states of the network connection.
➢Applicability : An object behavior depends on its state and it must changes its
behavior at run-time depending on that state.

➢Structure :
➢Participants :
• Context (TCP Connection) : Defines the interface of interest to clients.
• State (TCP state ) : Defines an interface for encapsulating the behavior
associated with a particular state of the content.
• Concrete State subclasses (TCP established) :Each subclass implements a
behavior associated with a state of the context.

➢Collaboration : Context delegates state specific request to the current concrete

state object.
• A context may pass itself as an argument to the state object handling the
request.

➢Consequences : It localizes state specific behavior and partitions behavior for

different states, it makes state transaction explicit, state objects can be shared.
➢Implementation : The state has 4 issues.
1.Who defines the state transactions. 2.A table based alternative.
3.Creating and destroying state object. 4.Using dynamic inheritance.

➢Known uses : Drawing editor framework.

➢Related pattern : The flyweight patters explains when and how state objects can
be shared
 Template method
➢Intent : Template method lets subclasses redefine certain steps of an
algorithm without changing the algorithm's structure.

➢Motivation : Consider an application framework that provides Application

and Document classes. The Application class is responsible for opening
existing documents stored in an external format, such as a file. A Document
object represents the information in a document once it's read from the file.

➢Applicability : To implement the invariant parts of an algorithm once and

leave it up to subclasses to implement the behavior that can vary.
➢Structure :
➢Participants :
• Abstract Class (Application) : Defines abstract primitive operations that
concrete subclasses define to implement steps of an algorithm.
• Concrete Class (My Application) : Implements the primitive operations to
carry out subclass-specific steps of the algorithm.

➢Collaboration : Concrete class relies on abstract class to implement the

invariant steps of the algorithm.

➢Consequences : Template methods are a fundamental technique for code reuse.

• They are particularly important in class libraries, because they are the
means for factoring out common behavior in library classes
➢Implementation : There are 3 issues in template method .
1.Using c++ access control. 2.Minimising primitive operation.
3.Naming convention.

➢Known uses : Template methods.

➢Related patterns : Factory method are often called by template methods.

• Templates methods use inheritance to vary part of an algorithm.