Behavioral Design Patterns part 2 OOD Course Hadassah

Behavioral Design Patterns (part 2) OOD Course Hadassah Academic College Solange Karsenty

3. Strategy • A program must switch between complex algorithms dynamically • For example, a document editor has several rendering algorithms, with different time/beauty tradeoffs • Word is a common example 03 November 2020 Object Oriented Design Course 2

The Requirements • Algorithms are complex, would be havoc to have them inside the one Document class • Switch algorithms dynamically • Easy to add new algorithms 03 November 2020 Object Oriented Design Course 3

The Solution • Define an abstract class that represents an algorithm: class Renderer { void render(Document *d) = 0; } • Each specific algorithm will be a descendant class Fast. Renderer, Tex. Renderer, … 03 November 2020 Object Oriented Design Course 4

The Solution II • The document itself chooses the rendering algorithm: class Document { render() { renderer->render(this); } set. Fast. Rendering() { renderer = new Fast. Renderer(); } private: Renderer *renderer; } 03 November 2020 Object Oriented Design Course 5

The Go. F UML 03 November 2020 Object Oriented Design Course 6

Participants • Strategy – declares an interface common to all supported algorithms. Context uses its interface to call the algorithm defined by a Concrete. Strategy. • Concrete. Strategy – implements a specific algorithm using the Strategy interface. • Context – is configured with a Concrete. Strategy object. – maintains a reference to a Strategy object. – may define an interface for Strategy to use to access its data 11/3/2020 Object Oriented Design Course 7

Applicability • Many related classes differ only in their behavior. • You need different variants of an algorithm. Strategies can be used as a class hierarchy of algorithms. • An algorithm use data structures that clients shouldn't know about. • A class defines many behaviors, and these appear as multiple conditionals in its operations. 11/3/2020 Object Oriented Design Course 8

Consequences • Families of related algorithms – Hierarchies of Strategy factor out common functionality of a family of algorithms for contexts to reuse. • An alternative to subclassing – Subclassing a Context class directly hard-wires the behavior into Context, making Context harder to understand, maintain, and extend. – Encapsulating the behavior in separate Strategy classes lets you vary the behavior independently from its context, making it easier to understand, replace, and extend 11/3/2020 Object Oriented Design Course 9

Consequences • Strategies eliminate conditional statements. • Encapsulating the behavior into separate Strategy classes eliminates conditional statements for selecting desired behavior. • A choice of implementations • Strategies can provide different implementations of the same behavior with different time and space trade-offs. • Clients must be aware of different strategies. • A client must understand how Strategies differ before it can select the appropriate one. • You should use the Strategy pattern only when the variation in behavior is relevant to clients. 11/3/2020 Object Oriented Design Course 10

Consequences • Communication overhead between Strategy and Context. • The Strategy interface is shared by all Concrete. Strategy classes. • It's likely that some Concrete. Strategies will not use all the information passed to them through this common interface. • To avoid passing data that get never used, you'll need tighter coupling between Strategy and Context. • Increased number of objects • can reduce this overhead by implementing strategies as stateless objects that context can share • The Flyweight pattern describes this approach in more detail. 11/3/2020 Object Oriented Design Course 11

Consequences • Inheriting a strategy would deny a dynamic switch • Some strategies may not use all information passed from Context • In some cases strategy objects are optional 03 November 2020 Object Oriented Design Course 12

Known Uses • Document rendering programs • Compiler code optimizations • Different heuristic algorithms (games, portfolio selection) • Different memory management schemes (Booch components) • Validation of dialog boxes (optional strategies, Borland Object. Windows) 03 November 2020 Object Oriented Design Course 13

//Strategy. Example test application class Strategy. Example { public static void main(String[] args) { Context context; // Three contexts following different strategies context = new Context(new First. Strategy()); context. execute(); context = new Context(new Second. Strategy()); context. execute(); context = new Context(new Third. Strategy()); context. execute(); } } // The classes that implement a concrete strategy should implement this // The context class uses this to call the concrete strategy interface Strategy { void execute(); }

// Implements the algorithm using the strategy interface class First. Strategy implements Strategy { public void execute() { System. out. println("Called First. Strategy. execute()"); } } class Second. Strategy implements Strategy { public void execute() { System. out. println("Called Second. Strategy. execute()"); } } class Third. Strategy implements Strategy { public void execute() { System. out. println("Called Third. Strategy. execute()"); } } // Configured with a Concrete. Strategy object and maintains a reference to a Strategy object class Context { Strategy strategy; // Constructor public Context(Strategy strategy) { this. strategy = strategy; } public void execute() { this. strategy. execute(); } }

4. State • Allow an object to alter its behavior when its internal state changes • For example, most methods of a TCPConnection object behave in different ways when the connection is closed, established or listening • How do we encapsulate the logic and data of every state? 03 November 2020 Object Oriented Design Course 16

The Requirements • A class has a state diagram, and many methods behave in wildly different ways in different states • When in a state, only allocate memory for data of that state • The logic of a specific state should be encapsulated 03 November 2020 Object Oriented Design Course 17

Pattern of Patterns • Encapsulate the varying aspect – State of an object • Interfaces – Let’s have a TCPState interface that has all the statesensitive methods • Inheritance describes variants – TCPEstablished, TCPListen and TCPClosed implement the interface • Composition allows a dynamic choice between variants 03 November 2020 Object Oriented Design Course 18

The Solution II • A TCPConnection codes state transitions and refers to a TCPState 03 November 2020 Object Oriented Design Course 19

The UML 03 November 2020 Object Oriented Design Course 20

Participants • Context – defines the interface of interest to clients. – maintains an instance of a Concrete. State subclass that defines the current state. • State – defines an interface for encapsulating the behavior associated with a particular state of the Context. • Concrete. State – each subclass implements a behavior associated with a state of the Context. 11/3/2020 Object Oriented Design Course 21

Collaborations • Context delegates state-specific requests to the current Concrete. State object. • A Context may pass itself as an argument to the State object so that the State object can access the context if necessary. • Context is the primary interface for clients. Clients don't have to deal with the State objects directly. • Either Context or the Concrete. State objects are responsible for state transitions. 11/3/2020 Object Oriented Design Course 22

Consequences • In complex cases it is better to let states define transitions, by adding a Set. State method to Context • This pattern is really a workaround for the lack of dynamic inheritance (Changing the behavior for a particular request could be accomplished by changing the object's class at run-time. ) • State is very much like Strategy • State = Many (small) actions • Strategy = One (complex) action

Consequences • States may be created on-demand or on Context’s creation – Creating State objects only when they are needed and destroying them thereafter. • This approach preferable when states to be entered aren't known at run-time, and contexts change state infrequently. • avoids creating objects that won't be used. – Creating State objects ahead of time and never destroying them • This approach is better when state changes occur rapidly. • Instantiation costs are paid once up-front, and there are no destruction costs at all. • The Context must keep references to all states that might be entered. • State objects can be shared – If State objects have no instance variables, they are essentially flyweights with no intrinsic state. Contexts can share such a State object.

Known Uses • Streams and connections • Different tools on a drawing program – Select, Erase, Crop, Rotate, Add, … 03 November 2020 Object Oriented Design Course 25

5. Command • Encapsulate commands as objects • We’ll take the uses one by one: – Undo/Redo – Macros – Queues and logs – Version control – Crash recovery – Message Grouping 03 November 2020 Object Oriented Design Course 26

The Requirements I • Undo / redo at unlimited depth • Only store relevant data for undo • Easy to add commands 03 November 2020 Object Oriented Design Course 27

The Solution • Repesent a command as a class: class Command { public: virtual void execute() = 0; virtual void undo() = 0; } 03 November 2020 Object Oriented Design Course 28

The Solution II • Concrete commands hold undo data: class Delete. Line : public Command { void execute() { line = document->get. Line(); document->remove. Line(); } void undo() { document->add. Line(line); } private: Line line; } 03 November 2020 Object Oriented Design Course 29

The Solution III • Keep a list of executed commands: Array<Command*> commands; int i; • When you click the ‘Undo’ button: commands(i)->undo(); i--; • When you click the ‘Redo’ button: commands(i)->execute(); i++; 03 November 2020 Object Oriented Design Course 30

The Solution IV • Whenever a command is activated: commands. add(new_command); i = commands. count(); • When you save a document: document->save(); commands. clear(); i = 0; • The commands list may or may not be limited in size • Only relevant undo data is kept 03 November 2020 Object Oriented Design Course 31

The Requirements II • Macros are a series of commands • Any command with any of its options may be used • There also for and while loops, if statements, calls to other macros. . . 03 November 2020 Object Oriented Design Course 32

The Solution • A macro is a Composite Command • if, for, while are Decorator Commands 03 November 2020 Object Oriented Design Course 33

The Requirements III • Commands are accessible from menus as well as toolbars • A command may be available from more than one place • We’d like to configure the menus and toolbars at runtime 03 November 2020 Object Oriented Design Course 34

The Solution • Each Menu. Item or Toolbar. Item refers to its command object • Just as it refers to an image • The command can be configured – Less command classes • Macros fit in the picture as well! 03 November 2020 Object Oriented Design Course 35

The Requirements IV • Keep multiple versions of a document • When saving, only store the changes from the previous version 03 November 2020 Object Oriented Design Course 36

The Solution • The changes are exactly the list of commands since the last version was loaded • In addition, a compaction algorithm is needed for commands that cancel each other • Save = Serialize the compacted list • Load = Read early version and call execute on command lists 03 November 2020 Object Oriented Design Course 37

Go. F UML

• Command Participants – declares an interface for executing an operation. • Concrete. Command – defines a binding between a Receiver object and an action. – implements Execute by invoking the corresponding operation(s) on Receiver. – When commands are undoable, Concrete. Command stores state for undoing the command prior to starting Execute. • Client – creates a Concrete. Command object and sets its receiver. • Invoker – invokes Execute on the command to carry out the request. • Receiver – knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver.

Consequences • Command decouples the object that invokes the operation from the one that knows how to perform it. • Commands are first-class objects that can be manipulated and extended. • Commands can be assembled into a Composite command. • It's easy to add new Commands, because you don't have to change existing classes.

Implementation Issues • How intelligent should a command be? – merely defines a binding between a receiver and the actions that carry out the request. – implements everything itself without delegating to a receiver at all. – in between, it has enough knowledge to find its receiver dynamically.

Implementation Issues: undo and redo • A Concrete. Command class might need to store state that can include: • the Receiver object, • the arguments to the operation performed on the receiver, • original values in the receiver that can change as a result of handling the request. The receiver must provide operations that let the command return to its prior state • one level of undo: store only the command executed last. • multiple-level undo and redo: history list of commands that have been executed. • If an undoable command can change its state on execution, it must be copied before it can be placed on the history to distinguish different invocations of the same command.

)More (!Known Uses • Programs log commands to disk so they can be used in case of a crash – Works, since commands are small – Usually in a background thread • Commands can be grouped and sent as one command to a server – Grouping for efficient communication – Grouping to define a transaction – Works even for user defined macros! 03 November 2020 Object Oriented Design Course 43

Summary • Pattern of patterns – Encapsulate the varying aspect – Interfaces – Inheritance describes variants – Composition allows a dynamic choice between variants • Design patterns are old, well known and thoroughly tested ideas – Over twenty years! 03 November 2020 Object Oriented Design Course 44