Pattern Examples Behavioural

Transcription

1 Pattern Examples Behavioural based on patterns in Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley, ISBN PE2-1

2 Iterator Pattern Intent» Access elements of a container sequentially without exposing the underlying representation Motivation» Be able to process all the elements in a container» Different iterators can give different sequential ordering > Binary tree preorder, inorder, postorder > Do not need to extend container interface PE2-2

3 Iterator Example BINARY_TREE size insertleft ( NODE, ELEMENT ) remove ( PARENT, NODE )... TREE_ITERATOR Iterator knows the internal structure export all relevant features to it make_inorder make_preorder make_postorder next alldone item PE2-3

4 Iterator Example Client tree_items : TREE_ITERATOR... from!! tree_items.make_inorder ( a_tree ) until tree_items.alldone loop item := tree_items.item process ( item ) tree_items.next end loop PE2-4

5 Iterator Structure Diagram ITERATOR * CONTAINER + size add remove next * alldone * item * CONCRETE_ITERATOR + make_1 make_2 next alldone item PE2-5

6 Iterator Applicability Access a container s contents without knowing about or using its internal representation Support multiple traversals Provide a uniform interface for traversing a container s contents» Support polymorphic iteration PE2-6

7 Iterator Participants Iterator» Defines the interface for accessing and traversing a container s contents Concrete iterator» Implements the iterator interface» Keeps track of the current position in the traversal Container» Could provide a method to create an instance of an iterator > Done in Java due to the poor export control in Java PE2-7

8 Iterator Collaborations Concrete iterator» Keeps track of the current object in the container» Computes the next object in a sequence of the container s objects PE2-8

9 Iterator Consequences Supports variations in the traversal of a container» Complex containers can be traversed in different ways > Trees and graphs» Easy to change traversal order > Replace iterator instance with a different one Iterators simplify the container interface» Do not need iterator interface in container interface Multiple simultaneous traversals» Each iterator keeps track of its own state PE2-9

10 Iterator Implementation Can implement null iterators» alldone is always True Useful in traversing tree structures» At each level ask for iterator for children» At leaf level get the null iterator» No exceptions at the boundary PE2-10

11 Inorder Traversal Binary Tree public Enumeration inorderlrtraversal() { return new Enumeration() { Declare variables needed by the enumeration { Initialization program for the enumerator } } public boolean hasmoreelements() { Provide the definition } public Object nextelement() { Provide the definition } PE2-11

12 Inorder Traversal Binary Tree 2 // Declare variables needed by the enumeration private Stack btstack = new Stack(); { // Initialization program for the enumerator // Simulate recursion by programming our own // stack. Need to get to the leftmost node as it // is first in the enumeration Node node = tree; root } while (node!= null) { btstack.add(node); node = node.left; } top of stack PE2-12

13 Inorder Traversal Binary Tree 3 public boolean hasmoreelements() { return! btstack.isempty(); } PE2-13

14 Inorder Traversal Binary Tree 4 top of stack initially root InitStack after call after call An enumerator is always 1 element ahead of the user 6 top of stack after first call to nextelement top of stack after second call to nextelement PE2-14

15 Inorder Traversal Binary Tree 5 public Object nextelement() { if (btstack.isempty()) throw new NoSuchElementException(); Node node = (Node) btstack.remove(); Object result = node.datum; // next data to return if (node.right!= null) { // Find next sequence node node = node.right; do { btstack.add(node); // Get leftmost node in node = node.left; // right subtree } while (node!= null); } } return result; Notice that an enumerator is always 1 element ahead PE2-15

16 Visitor Pattern Intent» Represent an operation to be performed on the components of an object structure» Define new operations on the structure without changing classes representing the components PE2-16

17 Visitor Motivation Motivation» Consider a compiler using an abstract syntax tree to represent the program NODE * type_check * generate_code * pretty_print * Operations spread out OO style but... difficult to add a new operation VAR_NODE ASSIGN_NODE type_check generate_code pretty_print... type_check generate_code pretty_print PE2-17

18 Visitor Example» Consider programs to process SGML tags SGML_TAG * tangle * weave * display * Want to add literate programming processors need to modify all classes recompile everything including deferred classes P_TAG tangle weave display... LI_TAG tangle weave display PE2-18

19 Visitor Motivation 2 Need Node classes to be independent of the operations but still make use of polymorphism Have the notion of the Nodes accepting visitors and directing them to the appropriate operation Have two hierarchies» Node hierarchy» Operation hierarchy PE2-19

20 BON for SGML example * VISITOR * SGML_TAG PS_GENERATE LI_TAG Same structure for each operation Same structure for each tag PE2-20

21 Visitor Applicability Object structure contains many classes of objects with differing interfaces and want to perform operations that depend on their concrete classes Many distinct and unrelated operations need to be performed» Do not want or are unable to clutter the concrete classes with these operations» Keep the related suboperations (specific to each concrete class) together» Put operations into only those applications that need them PE2-21

22 Visitor Applicability 2 The classes defining the object structure rarely change, but you often want to define new operations over the structure» Changing object structure means > redefining the interface to all visitors which is costly PE2-22

23 Visitor General Structure VISITOR * visit_elem_a ( ELEM_A ) * visit_elem_b ( ELEM_B ) *... ELEMENT * accept ( VISITOR ) *... CONCRETE_VISITOR_1 + visit_elem_a ( ELEM_A ) visit_elem_b ( ELEM_B )... CONCRETE_ELEM_A + accept ( VISITOR )... CONCRETE_ELEM_B + CONCRETE_VISITOR_2 + PE2-23

24 Visitor Participants Element» Defines an accept method for Visitors Concrete element» Implements the accept method for Visitors Visitor» Declares visit operation for each CONCRETE_ELEM class. > Visitor accesses the element from its particular interface PE2-24

25 Visitor Participants 2 Concrete visitor» Implements each operation declared by Visitor > Each operation implements a fragment of the algorithm defined for the concrete visitor > Provides the context for the algorithm > State accumulates throughout processing» Implements the high level organization > Enumerating the elements > Processing each in turn PE2-25

26 Visitor Collaboration Concrete visitor loops over the elements Visitor sends accept to the element telling them which visitor Element sends visit_element back to visitor» Selects which method in the visitor to execute 1 accept ( CONCRETE_VISITOR ) 2 visit_li_tag( CONCRETE_ELEMENT ) 1 CONCRETE_VISITOR 2 CONCRETE_ELEM PE2-26

27 Visitor TAG Implementation deferred class SGML_TAG feature accept ( VISITOR visitor ) is deferred end other features... end class LI_TAG inherit SGML_TAG feature accept (VISITOR visitor) is do visitor.visit_li_tag ( Current ) end other features... end PE2-27

28 Visitor VISITOR Implementation deferred class VISITOR feature -- Have one "visit" routine for each command visit_li_tag ( LI_TAG tag ) is deferred end visit_p_tag ( P_TAG tag) is deferred end visit_ul_tag (UL_TAG tag ) is deferred end... end PE2-28

29 Visitor Concrete Visitor Implementation class CONCRETE_VISITOR inherit VISITOR feature get_elements // Attaches elements to the iterator while elements.alldone do elements.item.accept ( Current ) elements.forth end visit_li_tag ( LI_tag tag ) is... do semantic action... end visit_ul_tag ( UL_tag tag ) is... do semantic action... end visit_p_tag ( P_tag tag ) is... do semantic action... end... // and all the rest of the tags end PE2-29

30 Visitor Consequences Adding new operations is easy» New operation implements visitor interface for the components» All the fragments of the visitor algorithm are in one file related behaviours are all in one file > Easier to make sure that components are working in unison» Unrelated operations and fragments are in other visitor classes» Contrast with having to change each of the component classes to have the operation fragment > Each class has a fragment of each of the operations PE2-30

31 Visitor Consequences 2 Adding new concrete elements is difficult» Need to modify visitor class» Need to modify each concrete visitor > Can sometimes simplify as many elements have common behaviour (default behaviour) that can be specified at concrete visitor level 1. > Create subclasses of level 1 for more specific behaviour for the new elements Only program the new elements» For many structures components do not change rapidly so this is not a problem PE2-31

32 Example Multi-Level Visitor Build general internal ADT PARSER + SGML VISITOR * Echo input from internal ADT EMITTER + PARSER_ TANGLE Extend ADT for program references EMITTER_ TANGLE Output program text for compiler EMITTER_ PS Output in Postscript PE2-32

33 Visitor Consequences 3 Works across class hierarchies» Contrast with Iterator Pattern PE2-33

34 Master-Slave Pattern Intent applies to objects» Handles computation of replicated services in a system so as to achieve fault tolerance and robustness» Independent components providing the same services (slaves) are separated from a component (master) responsible for invoking them, and for selecting a particular result from the slaves Motivation» Fault tolerance is critical in many systems» Replication of services and delegation of the same task to several suppliers is a common strategy PE2-34

35 Master-Slave Object Communication SENSOR ENERGY_ BEING 1 MAX_FOOD 2 SENSOR SENSOR Scenario: Hungry energy being 1 Request radiation_level 2 Poll sensors return maximum radiation_level SENSOR SENSOR PE2-35