COSC 3351 Software Design. Design Patterns Behavioral Patterns (II)

Transcription

1 COSC 3351 Software Design Design Patterns Behavioral Patterns (II) Spring 2008 Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Object Abstract Factory Adapter(object) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Façade Flyweight Proxy Observer State Strategy Visitor Memento 1

2 Memento Intent: Without violating encapsulation, capture and externalize an object s internal state so that the object can be restored to this state later. Applicability: Use the memento pattern when A snapshot of an object s state must be saved so that it can be restored to that state later, and A direct interface to obtaining the state would expose implementation details and break the object s encapsulation Structure Originator Memento Caretaker state SetMemento(Memento m) CreateMemento() state GetState() SetState() state = m->getstate(); return new Memento(state); 2

3 Participants Memento: stores internal state of the Originator object protects against access by objects other than the originator Originator: creates a memento containing a snapshot of its current internal state uses the memento to restore its internal state Caretaker: is responsible for the memento s safekeeping never operates on or examines the contents of a memento Implementation Mementos have two interfaces: a wide one for the originators: C++ usually relies on making the Originator a friend of Memento + making Memento s wide interface private a narrow one for other objects: public interface 3

4 class Originator { Memento* CreateMement(); void* SetMemento( const Memento* ); private: State* _state; class Memento { // narrow public interface virtual ~Memento(); private: friend class Originator; Memento(); void SetState(State *); State* GetState(); private: State* _state; // implementation of the Do() and Undo() operations of // the Originator, assuming that it confirms to the command // pattern void Originator::Do() { Originator* ori = Originator::Instance(); _state = ori->creatememento(); // do whatever the code has to do void Originator::Undo() { Originator *ori = Originator::Instance(); ori->setmemento(_state); 4

5 State Intent: allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Applicability: use the state pattern when an object s behavior depends on its state, and it must change its behavior at run-time depending on the state. Operations have large, multipart conditional statements Advantages: Localizes state-specific behavior and partitions behavior for different states It makes state transition explicit State objects can be shared Structure Context Request() <<interface>> State Handle() state->handle(); ConcreteStateA ConcreteStateB Handle() Handle() 5

6 Participants Context: Define the interface of interest to clients Maintains an instance of a ConcreteState subclass that defines the current state State: Defines an interface for encapsulating the behavior associated with a particular state of the Context ConcreteState: Each subclass implements a behavior associated with a state of the Context. Example: TCP connection 6

7 class TCPOctetStream; class TCPState; class TCPConnection { TCPConnection(); void ActiveOpen(); void PassiveOpen(); void Close(); void Send(); void Acknowledge(); void Synchronize(); void ProcessOctet(TCPOctetStream* ); private: friend class TCPState; void ChangeState (TCPState *); private: TCPState* _state; TCPState duplicates the state-changing interface of TCPConnection each method takes an additional TCPConnection instance as a parameter can therefore access Data from TCPConnection and modify the state class TCPState { virtual void Transmit(TCPConnection*, TCPOctetStream*) virtual void ActiveOpen(TCPConnection* ); virtual void PassiveOpen(TCPConnection*); virtual void Close(TCPConnection*); virtual void Send(TCPConnection*); virtual void Acknowledge(TCPConnection*); virtual void Synchronize(TCPConnection*); protected: void ChangeState (TCPConnection*, TCPState *); // provide default implementations for all classes, e.g. void TCPState::Transmit(TCPConnection*, TCPOctetStream*) { void ActiveOpen(TCPConnection* ) { void PassiveOpen(TCPConnection*) { void Close(TCPConnection*) { void Send(TCPConnection*) { 7

8 TCPConnection::TCPConnection() { _state = TCPClosed::Instance(); void TCPConnection::ChangeState(TCPState *s ) { _state = s; void TCPConnection::ActiveOpen() { _state->activeopen(this); void TCPConnection::PassiveOpen() { _state->passiveopen(this); void TCPConnection::Close() { _state->close(this); void TCPConnection::Acknowledge() { _state->acknowledge(this); void TCPConnection::Synchronize() { _state->synchronize(this); class TCPEstablished:: public TCPState { static TCPState* Instance(); virtual void Transmit(TCPConnection*, TCPOctetStream*); virtual void Close(TCPConnection*); ; class TCPListen:: public TCPState { static TCPState* Instance(); virtual void Send (TCPConnection*); void TCPEstablished:: Close ( TCPConnection *s ) { // send FIN // receive ACK ChangeState ( s, TCPListen::Instance() ); void TCPEstablished::Transmit (TCPConnection *s, TCPOctetstream *o ) { s->processoctet(o); // this function does not change the state 8

9 Strategy Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Applicability: use the Strategy pattern when many related classes differ only in the behavior you need different variants of an algorithm you want to avoid to expose complex, algorithm-specific data structures a class defines many behaviors, and these appear as multiple conditional statements in the operation. Structure Context Contextinterface() <<interface>> Strategy Algorithminterface() ConcreteStrategyA Algorithminterface() ConcreteStrategyB Algorithminterface() 9

10 Participants Strategy: declares an interface common to all supported algorithms ConcreteStrategy: implements the algorithm using the Strategy interface Context: is configured with a ConcreteStrategy object, i.e. the Constructor takes a ConcreteStrategy object maintains a reference to a Strategy object may define an interface that lets Strategy accesss data Visitor Intent: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates Applicability: Use the Visitor pattern when an object structure contains many classes of objects with differing interfaces and you want to perform operations on these objects that depend on their concrete classes many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid polluting the classes with these operations the classes defining the object structure changes rarely, but you often want to define new operations on the structure 10

11 Structure Client <<interface>> Visitor VisitorConcreteElementA() VisitorConcreteElementB() ConcreteVisitorA VisitorConcreteElementA () VisitorConcreteElementB () ConcreteVisitorB VisitorConcreteElementA() VisitorConcreteElementB() ObjectStructure <<interface>> Element Accept(Visitor) v->visitorconcreteelementa(this); ConcreteElementA Accept (Visitor v) OperationA() ConcreteElementB Accept (Visitor v) OperationB() Participants Visitor: declares a Visit operation for each ConcreteElement in the object structure ConcreteVisitor: implements each operation declared by Visitor Element: defines an Accept operation that takes a visitor as an argument ConcreteElement: implements an Accept operation that takes a visitor as an Argument ObjectStructure: Can enumerate its elements May provide a high-level interface to allow the visitor to visit its elements May either be a composite or a collection such as a list or a set 11

12 Consequences Visitor makes adding new operations easy Adding a new ConcreteElement is hard, since you have to update all ConcreteVisitor classes The visitor pattern depends on Double Dispatch: the method calls depends on the Visitor and the Element. class Visitor { virtual void VisitElementA(ElementA *); virtual void VisitElementA(ElementA *); protected: Visitor(); class Element { virtual ~Element(); virtual void Accept(Visitor&) =0; protected: Element(); class ElementA : public Element { ElementA(); virtual void Accept(Visitor& v){ v.visitelementa(this); class ElementB : public Element { ElementB(); virtual void Accept(Visitor& v){ v.visitelementb(this); 12

13 // Example for a composite element class CompositeElement : public Element { CompositeElement(); virtual void Accept(Visitor&); private: List<Element*>* _children; void CompositeElement ::Accept (Visitor &v) { ListIterator<Element*> i(_children); for ( i.first();!i.isdone(); i.next() ){ i.currentitem()->accept(v); v.visitcompositeelement(this); Discussion of Behavioral Patterns Mediator and Observer are competing patterns Mediator encapsulates interactions easier to understand dependencies and logical flow Mediators are hardly ever reusable Observer distributes communication between objects more difficult to understand to understand the flow of communication easier to write reusable subjects and oberservers 13

14 Discussion of Behavioral Patterns Decoupling of Sender and Receiver Command: introduces a Command class between invoker and Receiver Observer: decouples senders ( subjects) from receivers (observers) by defining an interface for signaling changes in subjects. Observer objects and number of observers can however vary at runtime Mediator: decouples senders and receivers by not having direct references to each other, but only through the mediator Chain of Responsibility: passes requests along a chain of potential receivers. Summary of Design Patterns Design Patterns do not present new algorithms new programming techniques new methods for designing systems new theories for design Design Patterns do document established approaches present a uniform language to describe these approaches can help to cut down development time, since you do not have to reinvent the wheel for many scenarios. 14