Copyright © 1995 –2004 Active Frameworks Inc. - All Rights Reserved - V2.0Behavioral Patterns - Page L8-1 PS95&96-MEF-L15-1 Dr. M.E. Fayad Creationa l.

Copyright © 1995 –2004 Active Frameworks Inc. - All Rights Reserved - V2.0 Behavioral Patterns - Page L8-1

PS95&96-MEF-L15-1Dr. M.E. Fayad

Creational

Paradigm Shift, Inc.Software Factory

Behavioral

Structural

Lesson 8:Behavioral Patterns

Lesson 8:Behavioral Patterns

Object-Object-OrientedOriented

DesignDesign PatternPatternss



Lesson ObjectivesLesson Objectives

Objectives

Discuss the philosophy behind behavioral patterns

Explore the world of behavioral patterns

Present the following Patterns:

Command

Iterator



Behavioral Patterns

• Behavioral patterns characterize the ways in which classes and objects interact and distribute responsibilities

• Behavioral class patterns capture how classes cooperate with their subclasses to fulfill their semantics

– Example: Template Method pattern

• Behavioral object patterns describe how a group of peer objects cooperate to perform a task that no single object can carry out by itself

– Examples: Mediator, Observer, Command, and Strategy

• Behavioral compound patterns deal with behavior in recursive object structures

– Examples: Iterator



Behavioral Patterns

Command Pattern

• Topics– Command Definition

– Structure

– Menu-Command Example

– Problems it Solves

– Participants & Collaborations

– Benefits

– Related Patterns



Command Pattern: Definition

• Define an object that encapsulates a request. This is useful for:

– Configuring objects with different requests

– Implementing undoable operations

– Queuing or logging requests

• The requestor should not be required to:

– Have specific knowledge of the request

– Handle any dependencies that may be required to execute the request

– May or may not specify the target of the request

• Command pattern is also known as Action or Transaction



Command Pattern: Structure

target->Action();

Target

Action()

ConcreteCommand

Execute()

Command

Execute()Client Invoker

state

target



Menu Example

command->Execute();

Menu

Add(MenuItem)

Document

Open()Close()Cut()Copy()Paste()

Command

Execute()command

MenuItem

Clicked()

Application

Add(Document)Document(Current)

• Manus can be implemented easily with Command objects

• Each choice in a Menu is an instance of a MenuItem class

• An Application class creates these menus and their menu items along with the rest of the user interface

The Application class also keeps track of Document objects that a user has opened

• Manus can be implemented easily with Command objects

• Each choice in a Menu is an instance of a MenuItem class

• An Application class creates these menus and their menu items along with the rest of the user interface

The Application class also keeps track of Document objects that a user has opened



More Menu Example

document->Paste();

PasteCommand

Execute()

Document

Open()Close()Cut()Copy()Paste()

Command

Execute()

document

• Command subclasses store the target of the request and invoke one or more specific requests on the target. For example, PasteCommand supports pasting text from the clipboard into a Document

• PasteCommand’s target is the Document object it is supplied upon instantiation

• The execute operation invokes Paste on the target Document

• Command subclasses store the target of the request and invoke one or more specific requests on the target. For example, PasteCommand supports pasting text from the clipboard into a Document

• PasteCommand’s target is the Document object it is supplied upon instantiation

• The execute operation invokes Paste on the target Document



More Menu Example

name = AskUse()doc = new Document(name)application->Add(doc)doc->Open()

OpenCommand

Execute()AskUse()

Command

Execute()

application

OpenCommand’s Execute operation:

• Prompts the user for document name

• Creates a corresponding Document’s object

• Adds the document to the target application

• Opens the document

OpenCommand’s Execute operation:

• Prompts the user for document name

• Creates a corresponding Document’s object

• Adds the document to the target application

• Opens the document

Application

Add(Document)Document(Current)



More Menu Example

for all c in commandsc->Execute();

MacroCommand

Execute()

Command

Execute()

commands

• MacroCommand is a concrete command subclass that simply executes a sequence of commands

• MacroCommand has no explicit target, because the commands it sequences define their own target

• MacroCommand is a concrete command subclass that simply executes a sequence of commands

• MacroCommand has no explicit target, because the commands it sequences define their own target



Command Pattern: When & Where to Use

• Use when it is desirable to decouple the client from the target

• When flexibility and adaptability are required on a frequent basis



Command Functions

• These can be implemented as a single operation on a target

• Multiple operations on a target (similar to a MacroCommand)

• No operations on the target, the function is contained within the command



Command Pattern: Extensibility

• Adding a new Command type:– Initialize a menu item - simply another instance with a different

label

– Create another concrete Command class for the new Command type

• Adding a new target type:– Extend each Command to provide the function for the new target.

In this case, the target type should be supplied to the Command

OR

– Create another set of concrete Command classes specific to the target type

How to Expand: 1. Macro Commands

2. History Files, such as Trace

3. Undo which requires the saving of state

How to Expand: 1. Macro Commands

2. History Files, such as Trace

3. Undo which requires the saving of state



Command Pattern: Participants

• Command

– an interface for executing an operation (Do, Execute)

• ConcreteCommand (PasteCommand, OpenCommand)

– knows its target

– implements Execute by invoking the corresponding operation or operations on target

• Client (Application)

– creates a ConcreteCommand, sets its target

• Invoker (MenuItem)

– requests the Command to execute its operation

• Target (Document, Application)

– knows how to carry out the operations requested from commands. Any class may serve as a Target



Command Pattern: Collaborations

• The Client creates a ConcreteCommand and specifies its target

• The ConcreteCommand is stored by an invoker

• The invoker asks the command to perform its duties by calling Execute

• The ConcreteCommand invokes operations on its target to carry out the request



Command Pattern: Interaction Diagram

Target InvokerCommandClient

Command()

ExecuteAction()

AdoptCommand()



Command Pattern: Benefits

• Command decouples the object that invokes the operation from the one that actually has the knowledge to perform it

• Commands are first-class objects

• Commands can be assembled into composite Commands

• Command enforces an architecture that can be extended easily with new kinds of commands



Command Pattern: Related Patterns

• Composite can be used to implement MacroCommands

• A Memento can keep state the Command requires to undo its effect

• A Command that must be copied before being placed on the history list acts as a prototype



Behavioral Patterns

Iterator Pattern

• Topics– Iterator Definition

– Structure

– Problems it Solves

– Participants & Collaborations

– Solutions & Benefits

– Implementation Issues

– Related Patterns



Iterator Pattern: Definition

• Iterators provide a standard interface for enumerating the components of a collection (Lists, Bags, Sets, ...) or a composite object without exposing the object’s internal structure

• This “hides the gory details” of the implementation of the collection from the user of the collection

• Iterators are also known as Cursors or Streams

• There can be more than one iterator traversing over a collection at any time

• Each iterator maintains an index into the collection

• Each object is responsible for returning its own iterator



Iteration: Basic Idea

Initialize iteration for (first element;

iteration not over;

next element)

Process element



Iterator Pattern: When to Use It

• To provide a uniform interface for iterating over different structures

• To avoid exposing internal representation and implementation of the structure

• To provide multiple traversal strategies for aggregate object structures, such as collections or composite objects

• To simplify maintenance and extensibility when traversal algorithms are distributed across multiple classes



Iterator Pattern: Structure

return new ConcreteIterator

ConcreteIterator

Iterator

First()Next()IsDone()CurrentItem()

ConcreteObjectStructure

CreateIterator() First()Next()IsDone()CurrentItem()

ObjectStructure

CreateIterator()

Client



Iterator Pattern: Participants

• Iterator– provides an interface for enumerating elements

• ConcreteIterator

– encapsulates and defines a traversal strategy over ObjectStructure

– keeps track of the current position during traversal of the ObjectStructure

• ObjectStructure– defines an interface for returning an iterator

• ConcreteObjectStructure– accesses its elements– provides a ConcreteIterator for itself

• Client– uses a ConcreteIterator to access the elements of an ObjectStructure



Iterator Pattern: Collaborations

• The Client repeatedly requests the next element of the ObjectStructure from iterator. The iterator:

– keeps track of a “current object” in the ObjectStructure

– can return the “current object” to the Client

– can compute the next “current object” in sequence

• The Client will then perform some operation on the element

• If the ObjectStructure is a Composite then the Iterator has to store a path through the Composite to keep track of the current object and computing the next current object requires accessing the Composite.



Iterator Pattern: Alternative Implementations

• Who controls the Iteration?

• Who defines the traversal algorithm?

• How robust is the Iterator?

• Using polymorphic iterators in C++

• Iterators may have privileged access

• Iterators for Composites

• Null Iterator



Iterator Pattern: Client Requirements

• Easy to use

• Able to use different traversal algorithms on the collection

• Able to use the same interface on several different collections

• Shouldn’t affect the internals of the collection

• Performance efficiency

Sample Client Code

int foo(Clntype &collection)

{

for (collection.First();

!collection.IsDone();

collection.next() )

{

process(collection.

CurrentItem())

}

}



Iterator Pattern: Developer Requirements

• Shouldn’t expose the internals of the object structure

• Maintainable

• Extensible

• Reusable



Iterator Pattern: Design Solution #1

Using this scheme, client would write

template <Class Element>

void foo(Container<Element> &container)

{

for (collection.First(); !collection.IsDone(); collection.Next() )

cout << container.CurrentElement();

}

Idea

Each container type defines an iteration scheme. The class implements the iteration algorithm as well as any data structures needed for the iteration. This means that the object structure itself has all the methods and data to iterate over its own elements.

Container

Stack

StackAR StackLL



• Requirements/Advantages1. Easy to use interface

2. Interface is similar across different containers

3. Performance efficient

4. Containers can be iterated polymorphically

5. Flexible enough to allow inserts and deletes during iteration

• Disadvantages1. If a client wants to subclass one of the containers, it forces the client to

define an iteration algorithm for the new subclass

2. Creates a large class interface

3. Doesn’t allow simultaneous iterations over a container

4. We combined two concepts in a single class

Iterator Pattern: Solution #1 Analysis







{

Iterator<Element> *it = container.currentIterator():

for (it->First(); !it->IsDone(); it->Next() ) {

cout << it->CurrentElement();

}

delete it;

}

Idea

In the previous scheme, we have two concepts merged into one implementation. Now let’s try to separate the Iterator concept from the Container. The result is two class hierarchies. The iterator object defines the traversal algorithm and maintains the current state of the iteration.



Iterator

StackIterator

StackARIterator StackLLIterator

Container

Stack

StackAR StackLL

Iterator Pattern: More Design Solution #2



• Requirements/Advantages1. Easy to use interface




5. More than one iteration scheme can easily be provided

6. Iterator implementation can change without affecting container classes

7. Allows simultaneous iteration of a container

• Disadvantages1. Inserts and deletes may leave Iterators in an undefined state

2. The Iterator breaks the encapsulation of the object structure








{

Cursor c;

for (collection.First(c); !collection.IsDone(c); collection.next(c) ) {

cout << container.CurrentElement(c);

}

}

Idea

Let the object structure define the iteration algorithm while maintaining the state in another object called a Cursor. The Cursor is then an argument to each iteration function of the object.

Container

Stack

StackAR StackLL



• Requirements/Advantages

1. Easy to use interface




5. Allows simultaneous iterations over the same container

• Disadvantages

1. Inserts and deletes may leave Iterators in an undefined state

2. Users have to pass parameters to the iteration functions




Idea

Each container object will accept an operation (in the form of an object) and apply it to every element in the container. This becomes a framework which allows clients to “plug-in” their own objects.

Container

Stack

StackAR StackLL


InternalIterator

UserSupplied



• Requirements/Advantages

1. Easy to use interface




5. Removes the iteration syntax from the client, which no longer has to worry about incrementing the counter or checking for the ending condition

• Disadvantages

1. Can only work with one container object at a time. We cannot compare elements from different containers

2. Cannot have simultaneous iterations over the same container




Iterator Pattern: Related Patterns

• Composite: Iterators are often applied to collections and recursive structures like Composites

• Memento: The iterator can use a Memento to capture the state of an iteration where the Iterator stores the Memento internally

• Visitors: They can be combined with Iterators so that responsibility for an algorithm over a complex structure is distributed between both of them

– The Iterator’s Responsibility: Traversing the compound structure

– The Visitor’s Responsibility: Implementing algorithm steps for each node in the structure



Discussion QuestionsDiscussion Questions

Define the relationship between the Iterator pattern and Memento, Composite, and Visitor.

Describe the following patterns: State, Strategy, Steams, and Transaction.

Mark (T) for true or (F) for false

( ) 1. The Command pattern is used when it is desirable to decouple the client from the target.

( ) 2. The Commands are first-class objects.

( ) 3. Macro Commands, History files, and Undo are useful techniques for extensibility in the Command pattern.

( ) 4. The Iterator pattern provide a uniform interface for iterating over different aggregate structures.

( ) 5. For a Composite to support an Iterator, each component must be able to enumerate its children. (This leads naturally to Nested Iterators.)

( ) 6. Iterators simplify the class of the aggregate objects.

Copyright © 1995 –2004 Active Frameworks Inc. - All Rights Reserved - V2.0Behavioral Patterns - Page L8-1 PS95&96-MEF-L15-1 Dr. M.E. Fayad Creationa l.

Documents

behavioral patterns

behavioral patterns

world of behavioral

following patterns

fayad command pattern

command menuitem

command iterator slide

request command pattern