Design Patterns. Command. Oliver Haase

Transcription

1 Design Patterns Command Oliver Haase 1

2 Description Purpose: Encapsulate a command as an object. Allows to dynamically configure an invoker with a command object. Invoker can invoke command without knowing its specifics, nor the receiver of the command. Also Known As: Action, Transaction 2

3 Motivation & Remarks Most widely known application of the command pattern: event listeners for GUI programming Remark: Command pattern is the object-oriented counterpart of function pointers in procedural languages Remark II: If the command object contains only one operation, function pointers can be considered more lightweight and thus more appropriate 3

4 Remarks Remark III: In C#, a function pointer is called a delegate. Example: // C# public delegate boolean FUNC(object x, object y); public boolean Compare (object x, object y) {... public boolean contains (object x, object[ ] field) { CMP_Func myfuncobj = new FUNC(Compare) ; foreach ( object obj in field ) f if ( myfuncobj ( obj, x ) ) return true; return false; 4

5 Motivation In Java Swing, when a JButton is pressed, the button invokes the actionperformed method of a pre-registered ActionListener command object. The ActionListener interface contains only the actionperformed method. an ActionListener command object can be registered using the JButton's addactionlistener method. 5

6 Another Remark Remark IV: In Java, an anonymous class might be a good choice to avoid the fully-fledged declaration of a class for a single method that is called only once: JButton submitbutton = new JButton ( "submit" ) ; submitbutton.addactionlistener (new ActionListener( ) { public void actionperformed( ActionEvent e) { ) ; // do whatever is needed to submit 6

7 Sample Structure MyApplication JButton actionlistener ActionListener actionperformed() MyModel action() MyActionListener model actionperformed() model.action() 7

8 Applicability Use the command pattern if you want to dynamically configure an object with an action; support undo functionality; keep a log of the executed actions so they can be redone in case of a crash; model a complex transaction; in this case the encapsulation of the transaction in a command object reduces code dependencies. 8

9 General Structure creates a concrete command object and passes the receiver into it. Client invokes the command through the Command interface. Invoker command Command execute() declares interface for command invocation Receiver action() ConcreteCommand receiver execute() knows how to perform the action. receiver.action() defines action to be performed defines receiver 9

10 Interactions Client creates concrete command object and determines the receiver Invoker stores the concrete command object Invoker executes a request by invoking the command object's execute operation If a command can be undone, the command object stores the receiver's original state so it can be restored later The concrete command object implements the request by calling some operation at the receiver object 10

11 Undo & Redo How to implement chains of undos and redos: provide an additional undo operation in the Command interface Invoker stores the concrete command object in each ConcreteCommand class, store the state before execution of the execute operation; this may include: all parameters for the action performed by the receiver all state information of the receiver that might change due to the execution of the action ( memento pattern) receiver must allow command object to restore receiver's original state 11

12 Undo & Redo How to implement chains of undos and redos: Client stores all executed commands in a command history depth of command history determines number of possible undo/redo steps command objects are copied before insertion into command history 12

13 Consequences Command pattern decouples the entity that invokes a request (Invoker) from the one that knows how to implement it (Command) Command objects can be manipulated (configured) and extended as any other object. Command objects can be composed to build macro objects. For this purpose, the composite pattern can be employed. New command objects can easily be created without modifying existing classes. Command objects can be replaced at runtime useful, e.g., for context-sensitive menus 13

14 Related Patterns The Composite pattern can be used to build macro commands (in which case the MacroCommand class doesn't point to a receiver object) If a command needs to store the receiver's state (undo), it can use the Memento pattern If a command object needs to be copied before being inserted into the command history, then it behaves like a Prototype 14

15 Iterator 15

16 Purpose Give sequential access to the individual elements of a complex object structure without revealing its internals. Also known as: Cursor 16

17 Sample Structure Client List iterator() Iterator hasnext() next() Vector iterator() ArrayList iterator() ArrayListIterator hasnext() next() VectorIterator hasnext() next() 17

18 Consequences / Benefits Using an iterator, a structure can be traversed multiple times at the same time; in different orders without changing the structure s interface. 18

19 General Structure defines operation to create iterator instance uses concrete aggregate through Aggregate and concrete iterator through Iterator interface. Client defines interface to access and traverse elements of an aggregate Aggregate createiterator() Iterator hasnext() next() ConcreteAggregate createiterator() ConcreteIterator hasnext() next() creates concrete iterator return new ConcreteIterator() implements Iterator interface stores current position of traversal 19

20 Privileged Access Iterators usually have privileged access to the elements of an aggregate. This can be achieved through friend class concept (C++): make iterator friend of aggregate non-static member classes (Java): Beware, publication of an inner class instance implicitly also publishes outer instance. 20

21 Robust Iterators It can be dangerous to modify an aggregate while it is being traversed robust iterators don't get affected possible techniques: iterator works on deep copy of aggregate potentially out-dated snapshot iterator is registered with aggregate, aggregate notifies iterators about modifications 21

22 Java Iterator Interface the Java collection framework uses the Iterator pattern each implementation of Collection<E> implements the interface Iterable<E>: interface Iterable<E> { Iterator<E> iterator(); interface Iterator<E> { boolean hasnext(); E next(); void remove(); custom aggregate classes can and should also implement Iterable and provide appropriate iterators. 22

23 Java Iterator Interface sample usage: for ( Iterator<ElementType> it = aggregate.iterator(); it.hasnext(); ) { iterator.next().use(); or, as a for-each loop: for ( ElementType element : aggregate ) { element.use(); the for-each loop is internally translated into the above for loop. 23

24 Java Iterator Interface What s wrong with the following code snipplet? public static void usevector(vector<t> vector) { for (T element : vector) element.use(); Not threadsafe, because vector might get modified while being iterated! - This is true even though Vector is a synchronized collection. Concurrent modification of underlying collection may result in ConcurrentModificationException iterator fail-fast, but on a best effort basis, i.e. applications must not rely on it 24

25 Java Iterator Interface Possible Solutions: 1. copy vector, iterate on the copy performance cost, iterates over a potentially outdated snapshot 2. client-side locking: public static void usevector(vector<t> vector) { synchronized ( vector ) { for (T element: vector) element.use(); prevents other threads from modifying vector during iteration, but also from accessing vector at all! 25

26 Java Iterator Interface What s wrong with the following code snipplet? public static void filtervector(vector<t> vector) { for (T element : vector) if (!element.isvalid() ) vector.remove(element); Same thread modifies vector while being iterated ConcurrentModificationException! 26

27 Java Iterator Interface Solution: modify vector through iterator, not directly. public static void filtervector(vector<t> vector) { for (Iterator<T> it = vector.iterator(); it.hasnext(); ) if (! it.next().isvalid() ) it.remove(); 27

28 Hidden Iterators What s wrong with the following class? public class HiddenIterator { private final Set<Integer> set = new HashSet<Integer>(); public synchronized void add(integer i) { set.add(i); public synchronized void remove(integer i) { set.remove(); public void addtenthings() { Random r = new Random(); for ( int i = 0; i < 10; i++ ) add(r.nextint()); System.out.println( Added ten elements to + set); set.tostring() contains a hidden iterator not threadsafe! 28

29 Hidden Iterators The following methods that operate on collections all contain hidden iterators: tostring() hashcode() equals() called if collection is used as key or element of another collection containsall() removeall() retainall() constructors that take collections as arguments 29

30 Iterating Concurrent Collections Since Java 5.0, Collection framework contains several concurrent collections that allow for concurrent access while still being threadsafe, including: ConcurrentHashMap ( lock striping) CopyOnWriteArrayList ( new copy for each modification) ConcurrentLinkedQueue ( lock striping) Iterators on concurrent collections are weakly consistent traverse elements as they were at time of iterator construction cannot throw ConcurrentModificationException! 30

31 Related Patterns Iterators are often used for recursive structures such as Composita For iterator creation, aggregate defines a factory method Iterators can use the Memento pattern to store the state of an iteration. 31

32 Visitor 32

33 Purpose Separate algorithm from the object structure upon which it operates. 33

34 Motivation Consider the following list structure: Client List sum(): int chars(): String NIL sum(): int chars(): String Element tail IntElement head: int sum(): int chars: String CharElement head: char sum(): int chars: String [compare: J. Bloch, Effective Java, 2nd Edition, item 43: Return empty arrays or collections, not null] 34

35 Motivation public interface List { int sum(); String // even stateless public class Nil implements List public String chars() { return public int sum() { return 0; public abstract class Element implements List { protected final List tail; protected Element(List tail) { this.tail = tail; 35

36 public class IntElement extends Element { private final int head; public IntElement(int number, List tail) { super(tail); head = public String chars() { return public int sum() { return head + public class CharElement extends Element { private char head; public CharElement(char character, List tail) { super(tail); head = public String chars() { return head + public int sum() { return tail.sum(); 36

37 Motivation Sample Usage: public class Client { public static void main(string[] args) { List l = new IntElement(4, new CharElement('b', new CharElement('a', new IntElement(3, new Nil())))); System.out.println("Sum: " + l.sum()); System.out.println("Characters: " + l.chars()); 37

38 Motivation Problem: Introduction of a new operation, e.g. boolean contains (char c); requires modification of List interface IntElement class CharElement class Generally, of all classes of the object structure. 38

39 Key Idea Idea: Separate operations (sum(), chars(), ) into visitor classes that traverse the object structure. Prepare object structure to let operations traverse it. Add an accept(visitor) method to each element type. In each specific visitor, provide one visit(elementtype) operation per ElementType. To visit an element, visitor calls element s accept operation which in turn calls the visitor s appropriate visit(elementtype) operation. 39

40 Sample Structure Client List accept(visitor) Visitor visit(nil) visit(intelement) visit(charelement) NIL accept(visitor) Element tail SumVisitor visit(nil) visit(intelement) visit(charelement) CharVisitor visit(nil) visit(intelement) visit(charelement) IntElement head: int accept(visitor) CharElement head: char accept(visitor) 40

41 Sample Implementation public interface List { void accept(visitor // even stateless public class Nil implements List public void accept(visitor visitor) { visitor.visit(this); public abstract class Element implements List { protected List tail; protected Element(List tail) { this.tail = tail; public List gettail() { return tail; 41

42 Sample public class IntElement extends Element { private int head; public IntElement(int number, List tail) { super(tail); head = number; public int gethead() { return public void accept(visitor visitor) { visitor.visit(this); public interface Visitor { void visit(nil list); void visit(intelement list); void visit(charelement list); 42

43 Sample // must be run thread-confined public class SumVisitor implements Visitor { private int sum = public void visit(nil list) public void visit(intelement list) { sum += list.gethead(); public void visit(charelement list) { list.gettail().accept(this); public int getsum() { return sum; Please note: visitor can (and sometimes must) store state information. 43

44 Sample Implementation Sample Usage: public class Client { public static void main(string[] args) { List l = new IntElement(4, new CharElement('b', new CharElement('a', new IntElement(3, new Nil())))); SumVisitor sv = new SumVisitor(); l.accept(sv); System.out.println("Summe: " + sv.getsum()); CharsVisitor cv = new CharsVisitor(); l.accept(cv); System.out.println("Summe: " + cv.getchars()); 44

45 General Structure declares an overloaded visit operation for each concrete element type. defines accept operation with a visitor as argument. Client Visitor visit(concreteelementa) visit(concreteelementb) Element accept(visitor) implements accept operation, usually by calling visitor s appropriate visit operation. ConcreteElementA accept(visitor) ConcreteElementB accept(visitor) ConcreteVisitor visit(concreteelementa) visit(concreteelementb) provides implementation for each overloaded visit operation can store state information provides operation to retrieve final state Please note: Concrete elements need not have a common supertype. 45

46 Consequences of Modifications w/o visitor pattern with visitor pattern modify operation adapt all structural classes adapt only affected visitor modify object structure adapt only affected structural class adapt all visitor classes Visitor pattern is beneficial if object structure is more stable than operations on it. 46

47 Advanced Considerations The interaction sequence :Client v: ConcreteVisitor e:concreteelement e.accept(v) visit(this) might seem awkward. It is only necessary, because most OO languages (including Java and C#) support only single dispatch rather than double dispatch. 47

48 Advanced Considerations Desirable: in client, call visitor s appropriate overloaded visit operation, depending on element type :Client v: ConcreteVisitor e:concreteelement v.visit(e) doube dispatch: selection of visit depends on both e s type and v s runtime type 48

49 Advanced Considerations single dispatch polymorhism: method call v.visit(e) depends on v s runtime type, but only on e s static type. :Client v: ConcreteVisitor e:concreteelement e.accept(v) use single dispatch polymorhism to call correct e s accept method visit(this) use overloading to call correct visit method. 49

50 Advanced Considerations If client inspects the runtime type of an element, it can directly call the visitor s appropriate visit operations without the indirection via the element's accept operation:... if ( l instanceof Nil ) { v.visit((nil) list); if ( l instanceof IntElement ) { v.visit((intelement) list); if ( l instanceof CharElement ) { v.visit((charelement) list); 50

51 Advanced Considerations This task can be placed into visitor: public abstract class Visitor { public final void visit(list list) { if ( list instanceof Nil ) { visit((nil) list); if ( list instanceof IntElement ) { visit((intelement) list); if ( list instanceof CharElement ) { visit((charelement) list); abstract public void visit(nil list); abstract public void visit(intelement list); abstract public void visit(charelement list); 51

52 Advanced // must be run thread-confined public class SumVisitor extends Visitor { private int sum = 0; public void visit(nil list) { public void visit(intelement list) { sum += list.gethead(); visit(list.gettail()); public void visit(charelement list) { visit(list.gettail()); public int getsum() { return sum; 52

53 Advanced Considerations Now, list structure does not need accept method any more: public interface List { public class Nil implements List { public abstract class Element implements List { protected List tail; protected Element(List tail) { this.tail = tail; public List gettail() { return tail; 53

54 Advanced public class IntElement extends Element { private int head; public IntElement(int number, List tail) { super(tail); head = number; public int gethead() { return head; public class Client { public static void main(string[] args) { List l = new IntElement(4, new CharElement('b', new CharElement('a', new IntElement(3, new Nil())))); SumVisitor sv = new SumVisitor(); sv.visit(l); System.out.println("Summe: " + sv.getsum()); CharsVisitor cv = new CharsVisitor(); cv.visit(l); System.out.println("Summe: " + cv.getchars()); 54

55 Even More Advanced Considerations With introspection, the Visitor base class can do without the switch: public abstract class Visitor { final public void visit(list list) { Object[] os = {list; Class<?>[] cs = {list.getclass(); try { this.getclass().getmethod("visit", cs).invoke(this, os); catch ( Exception e) {... abstract public void visit(nil list); abstract public void visit(intelement list); abstract public void visit(charelement list); 55