11 Behavioral Pattern Venkat Subramaniam BDP1 Behavioral Patters

11. Behavioral Pattern Venkat Subramaniam BDP-1

Behavioral Patters • Concerned with algorithms assignment of responsibilities & • Patterns of Communication between Objects Venkat Subramaniam BDP-2

Chain of Responsibility Pattern “Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it” Venkat Subramaniam BDP-3

Example that would benefit from Chain Of Responsibility Pattern • Various types of Controls are used in an application. Controls handle certain events while they do not handle others. Each control may be invoked from other controls. An event not handled by a control must be passed on to its parent control. Venkat Subramaniam BDP-4

Example using Chain of Responsibility Pattern Client Event Handler handle. Event() Venkat Subramaniam Control 1 Control 2 handle. Event() BDP-5

When to use Chain Of Responsibility Pattern • More than one object may handle a request, and the handler isn’t known ahead of time. • One of several objects may be the intended receiver • Set of objects that handle request is dynamic Venkat Subramaniam BDP-6

Consequences of using Chain Of Responsibility • Reduced Coupling • Flexibility in assigning responsibilities – Distributes responsibilities among objects • Receipt isn’t guaranteed Venkat Subramaniam BDP-7

Chain Of Responsibility Vs. Other Patterns • Often used with Composite – Parent acts as Successor Venkat Subramaniam BDP-8

Iterator Pattern “Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation” Venkat Subramaniam BDP-9

Example that would benefit from Iterator • Several types of collections are available – List, Set, Queue, Vector • We are interested in performing some operation on each element in a collection, without regard to which collection we use Venkat Subramaniam BDP-10

Example using Iterator Pattern Aggregate Client Iterator Create. Iterator() First() Next() Is. Done() Current. Item() Concreate. Aggregate Concrete. Iterator Venkat Subramaniam BDP-11

When to use Iterator Pattern • Elements of an Aggregate needs to be accessed without exposing internal representation of the aggregate • multiple traversals on an aggregate • uniform traversal on different aggregates Venkat Subramaniam BDP-12

Consequences of using Iterator • Supports variations in the traversal • Simplifies interface of Aggregates • More than one traversal may be acting on the aggregate at any time Venkat Subramaniam BDP-13

Iterator Vs. Other Patterns • Often applied to recursive structures such as Composite • Factory method instantiate appropriate Iterator • Memento used in conjunction with Iterator stores memento internally to capture the state Venkat Subramaniam BDP-14

Mediator Pattern “Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently” Venkat Subramaniam BDP-15

Example that would benefit from Mediator • An application is used to design Wheels • The diameter of the rim is restricted by the Hub diameter • The tire diameter is dependent on the rim • The spokes length needs to be altered if hub diameter or rim diameter is changed Venkat Subramaniam BDP-16

Example using Mediator Pattern Hub Rim Mediator Spoke Tire Venkat Subramaniam BDP-17

When to use Mediator Pattern • Set of objects communicate in complex well defined way • You want to reduce interdependency between objects • Reusing object is difficult if it refers to several other objects • Behavior distributed between several classes must be customizable without lot of subclassing Venkat Subramaniam BDP-18

Consequences of using Mediator • Localizes behavior that may otherwise be distributed among several objects • Subclass mediator to change this behavior • Decouples Colleagues • Replaces many-to-many interactions with one-to-many interaction – Easy to maintain, extend and understand Venkat Subramaniam BDP-19

Mediator Vs. Other Patterns • Facade – In Mediator, Colleague objects know Mediator – In Facade subsystem classes do not see Facade • Colleagues may communicate with Mediator using Observer Venkat Subramaniam BDP-20

Memento Pattern “Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to its state later” Venkat Subramaniam BDP-21

Example that would benefit from Memento • You want to let the user modify an object • However the user may cancel the modification • You want to store the internal state of a complex object to restore it later Venkat Subramaniam BDP-22

Example using Memento Pattern Originator state Set. Memento(Memento m) Create. Memento() return new Memento(state) Venkat Subramaniam Memento state Get. State() Set. State() Caretaker state = m->Get. State() BDP-23

When to use Memento Pattern • A snapshot of an object’s state must be saved to restore later • you do not want to expose the implementation details of the internal state of an object, breaking its encapsulation Venkat Subramaniam BDP-24

Consequences of using Memento • Simplifies the Originator • Preserves encapsulation boundaries • May be expensive • Defining narrow and wide interfaces – How to ensure only originator accesses memento’s state • Caretaker is responsible for deleting memento – Lightweight caretakers may be burdened with large mementos Venkat Subramaniam BDP-25

Memento Vs. Other Patterns • Command – May use mementos to maintain state for undo operations • Iterator – Mementos can be used for storing internal state of iterators Venkat Subramaniam BDP-26

Observer Pattern “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically” Venkat Subramaniam BDP-27

Example that would benefit from Observer • You have several views of a document – Graph View – Tabular. View – Chart. View • The user may change the data of a document from any of the visible views • You want to keep all the views synched with the change to the document’s data Venkat Subramaniam BDP-28

Example using Observer Pattern Observers Abstract Document Attach(View observer. View) Detach(View observer. View) Notify() Your. Document Venkat Subramaniam Graph. View Update Tabular. View Chart. View BDP-29

When to use Observer Pattern • When an abstraction has two aspects one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently • Change to one object requires change to others – don’t know how many objects need change • Object is able to notify other objects without knowing who these objects are - don’t want tight coupling Venkat Subramaniam BDP-30

Consequences of using Observer • Abstract the coupling between observers and subject • Support for broadcast communication • Unexpected updates – May be expensive and untimely • May abstract a hint on the subject change Venkat Subramaniam BDP-31

Observer Vs. Other Patterns • Mediator may be used to mediate between several subjects and observers Venkat Subramaniam BDP-32

State Pattern “Allow an object to alter its behavior when its internal state changes. The object will appear to change its state” Venkat Subramaniam BDP-33

Example that would benefit from State Pattern • A train may run in forward or reverse mode. • When running in forward mode the head lights on the front engine are on and the tail lights on the back engine are on. • When running in reverse mode the reverse is true. • Acceleration will move the engine forward or backward depending on the mode Venkat Subramaniam BDP-34

Example using State Pattern Train turn. Head. Lights() turn. Tail. Lights() accelerate() Venkat Subramaniam current. Mode Train. Direction Forward. Mode Reverse. Mode turn. Head. Lights() turn. Tail. Lights() accelerate() BDP-35

When to use State Pattern • An object’s behavior depends on its state and must change its behavior at run-time depending on that state • Operations have large conditional statements that depend on the state. State pattern puts each branch of the conditional in a separate class. Venkat Subramaniam BDP-36

Consequences of using State • Localizes state-specific behavior and partitions behavior for different states • Makes state transitions explicit • State objects can be shared Venkat Subramaniam BDP-37

State Vs. Other Patterns • Flyweight pattern may be used to share state which may be singletons. Venkat Subramaniam BDP-38

Strategy Pattern “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it” Venkat Subramaniam BDP-39

Example that would benefit from Strategy Pattern • A property may be computed using one of several methods/algorithms • Each method comes with its own features and trade-offs – For instance, a method may converge towards a result at a faster rate but may use more memory – Another method may not require as much memory • Design your class such that the client may use any applicable method to compute property Venkat Subramaniam BDP-40

Example using Strategy Pattern Property method. To. Use Compute() Venkat Subramaniam Method. For. Property compute() Method 1 compute() BDP-41

When to use Strategy Pattern • Many related classes differ only in their behavior. Strategy provides a way to configure a class with one of many behaviors • Use different variants of an algorithm • Algorithm uses data that clients shouldn’t know about. Strategy avoids exposing complex algorithm-specific data structures • class defines many behaviors and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own strategy class. Venkat Subramaniam BDP-42

Consequences of using Strategy • • Families of related algorithms Alternative to subclassing Strategies eliminate conditional statements Choice of implementations • Clients must be aware of different strategies • Communication overhead between Strategy and Context • Increased number of objects Venkat Subramaniam BDP-43

Strategy Vs. Other Patterns • Often make good Flyweights Venkat Subramaniam BDP-44