1. Design Patterns in Java Chapter 21 Template Method Summary prepared by Kirk Scott 1

2. The Introduction Before the Introduction This is another chapter where I’m going to cut my losses I will only cover the first example given by the book, sorting, taken from the Java API I will not cover the additional material where the authors try to come up with examples out of whole cloth based on the fireworks scenario As a student, you are only responsible for the first example 2

3. The Template design pattern, at heart, is not very complicated The idea can be summarized as follows: You write the code for the outline of an algorithm, leaving certain steps of the algorithm as calls to other methods 3

4. If the overall algorithm is complex, this is a divide and conquer approach to code writing Whether the algorithm is complex or not, it also has another potential benefit By changing the subparts only, the overall algorithm may be applied to different kinds of objects, or may be made to differ in some other way, while the main outline of the algorithm remains unchanged 4

5. You may recall that in the previous chapter the authors explained that an algorithm may be realized through the implementation of more than one interacting method They found it helpful to illustrate this idea with a design consisting of more than one class, with each class providing a different implementation of a method with the same signature 5

6. I pointed out that an algorithm based on more than one method might arise in a different way One method might call other methods which implemented parts of the algorithm That is what the Template design pattern is all about 6

7. Book definition: The intent of the Template Method is to implement an algorithm in a method, deferring the definition of some steps of the algorithm so that other classes can redefine them. 7

8. A Classic Example: Sorting I would note that the book’s attempt at gender inclusiveness is interesting, but it seems to be somewhat anachronistic 8

9. The book observes that there are many different sorting algorithms However, fundamentally, each algorithm ultimately depends on the ability to do pairwise comparisons between two values or objects 9

10. From the perspective of the Template design pattern, this leads to two conclusions 1. You could, for example, implement a template for quick sort You could also implement a template for merge sort Each template could make use of a call to a method that supported the pairwise comparison of objects to be sorted 10

11. 2. You could also just be concerned with an implementation of merge sort However, you might be interested in applying it to different kinds of objects Or you might be interested in applying it to the same kinds of objects, but comparing those objects based on different characteristics at different times 11

12. The book now tackles the question of how sorting is done in at least some of the classes in the Java API I will cover the same material My presentation order and the details I choose to bring out may differ from the book’s presentation 12

13. The first thing to notice is that there are two parallel tracks to sorting in Java The first of the two tracks is based on what the API refers to as “natural sort order” In essence the second track is an extension that makes it possible to easily compare objects on some order other than the so- called natural order 13

14. In discussing both tracks, I will be considering the business of doing a pairwise comparison between objects first Then I will consider the question of a template method that makes use of the comparison I will take up the question of natural order first 14

15. There is an interface named Comparable in the Java API Let a class implement the Comparable interface This means that it implements a method named compareTo() with this signature and return type: compareTo(obj:Object):int In other words, given one instance of a class, it’s possible to compare it to another instance of that class 15

16. The compareTo() method contains the logic for comparison In straightforward cases, you would expect the comparison to be based on the value of (the most important) one of the instance variables of the object 16

17. If the return value is -1, the implicit parameter is less than the explicit parameter according to the natural order If the return value is 0, the implicit parameter is equal to the explicit parameter according to the natural order If the return value is 1, the implicit parameter is greater than the explicit parameter according to the natural order 17

18. Now, on to the question of a template method Not only does the Java API contain the Comparable interface, it also contains classes named Arrays and Collections The first thing to be careful about is not to confuse these classes with the class Array or the interface Collection 18

19. It is moderately inconvenient that the API contains a mixture of classes and interfaces where the names differ only in that one may be singular and another may be plural For background review, I note that the Array class is a concrete class where instances of the class are plain old arrays The Collection interface is at the root of the collection hierarchy, which contains all of the implementing classes like ArrayList, HashMap, etc. 19

20. So what are the classes Arrays and Collections? They are classes that contain methods that can be used to work on instances of arrays or collections 20

21. This is the first paragraph of the Java API for the Arrays class: “This class contains various methods for manipulating arrays (such as sorting and searching). This class also contains a static factory that allows arrays to be viewed as lists.” I scanned the methods listed for the class and found them all to be static 21

22. This is the first paragraph of the Java API for the Collections class: “This class consists exclusively of static methods that operate on or return collections. It contains polymorphic algorithms that operate on collections, "wrappers", which return a new collection backed by a specified collection, and a few other odds and ends.” 22

23. This is a simplistic analogy, but it might be helpful The Math class contains static methods for performing mathematical operations The Arrays and Collections classes contain static methods for performing operations on instances of these classes, both of which are characterized by having multiple elements 23

24. Take the Arrays class for example It has 18 different sort methods in it Most of these methods differ according to the type of element in the array that is passed in as the explicit parameter to be sorted If the elements of the array are a simple type, the sort order is clear 24

25. For example, if an array contains integers, the call to the sort method with that kind of explicit parameter will sort in numerical order based on the numerical comparison operator < For what it’s worth, if you look further into the documentation, you will find that the sorting algorithm that is implemented is a version of quick sort 25

26. The question is, how will an array be sorted if it contains references to objects? To make this a reasonable question, remember that for a garden variety array, you have to declare the type of the object in the array In other words, each of an array’s elements has to be an instance of the same class 26

27. Here is part of the Java API documentation for that sort() method: public static void sort(Object[] a)Object Sorts the specified array of objects into ascending order, according to the natural ordering of its elements. All elements in the array must implement the Comparable interface. 27

28. What this means is that the sort() method will successfully work on an array if the elements of the array are of a class that implements the Comparable interface If that’s the case, then the sorting of the array will correspond to the results obtained by a pairwise comparison of its elements using the compareTo() method of that class For what it’s worth, if you look further into the documentation, you will find that the sorting algorithm that is implemented is a version of merge sort 28

29. The situation with the Collections class is similar, but simpler It does not have a large number of sort() methods because a collection can only contain object references, not simple types It has two sort() methods The first sort() method is analogous to the sort() method for the Arrays class 29

30. Here is part of the Java API documentation for that sort() method: public static > void sort(List list)ComparableList Sorts the specified list into ascending order, according to the natural ordering of its elements. All elements in the list must implement the Comparable interface. 30

31. The signature of this sort() method differs from the signature of the sort() method in the Arrays class in two ways: First of all, in general a collection can contain references to different kinds of objects Angle bracket notation can be used to specify a single object type that a collection contains 31

32. Secondly, in the Arrays class, the sort() method was void and it sorted the explicit parameter directly In the Collections class, the sort() method returns a sorted version of the explicit parameter 32

33. Aside for those two differences, the sort() methods in Arrays and Collections are similar They both rely on the natural order defined on the objects by their implementation of the Comparable interface The sort order results from the pairwise application of compareTo() to the elements of the collection 33

34. Recall this observation made earlier: 1. You could, for example, implement a template for quick sort You could also implement a template for merge sort Each template could make use of a call to a method that supported the pairwise comparison of objects to be sorted 34

35. The foregoing examples illustrate the idea that if you factor out the individual comparison operation, different sorting algorithms can rely on that As noted, if you look into the documentation, simple types are sorted using quick sort and objects are sorted using merge sort, but all sorting relies on the ability to compare pairs of elements 35

36. Now recall this observation, made earlier: 2. You could also just be concerned with an implementation of merge sort However, you might be interested in applying it to different kinds of objects Or you might be interested in applying it to the same kinds of objects, but comparing those objects based on different characteristics at different times 36

37. Specifically consider applying the same sorting algorithm to the same kinds of objects, but wanting to sort them on a different characteristic This is the motivation behind a different interface in the Java API and a different kind of sort() method that appears in the Arrays and Collections classes 37

38. There is an interface named Comparator in the Java API Let a class implement the Comparator interface This means that it implements a method named compare() with this signature and return type: compare(o1:Object, o2:Object):int Notice that this isn’t literally a static method, but it is similar to one in form Given two instances of a class, it’s possible to compare them with each other 38

39. The meaning of the integer return value is the same as for compareTo(), but notice that the results of compare() are not styled the natural order If the return value is -1, the first explicit parameter is less than the second explicit parameter If the return value is 0, the first explicit parameter is equal to the second explicit parameter If the return value is 1, the first explicit parameter is greater than the second explicit parameter 39

40. The Arrays and Collections classes both contain a sort() method that takes as parameters both an array or collection to be sorted, as well as an instance of a class that implements the Comparator interface for the elements of the array or collection 40

41. Here is part of the Java API documentation for that sort() method in the Arrays class: public static void sort(T[] a, Comparator c)Comparator Sorts the specified array of objects according to the order induced by the specified comparator. 41

42. Here is part of the Java API documentation for that sort() method in the Arrays class: public static void sort(T[] a, Comparator c)Comparator Sorts the specified array of objects according to the order induced by the specified comparator. 42

43. Here is part of the Java API documentation for that sort() method in the Collections class: public static void sort(List list, Comparator c)List Comparator Sorts the specified list according to the order induced by the specified comparator. 43

44. Notice that the definitions use the angle bracket notation like the definition for the other sort() method in Collections Also recall that in Collections there are only two sort() methods The first was the one on natural order The second is this one As the documentation states, using the Comparator interface, you can sort objects on any of their characteristics, not just their natural order, defined using the Comparable interface 44

45. Finally, this is the grand conclusion in the context of the Template design pattern For arrays and collections containing objects, there is one underlying sorting algorithm, merge sort However, the sort order that is obtained can be changed by changing the pairwise comparison that is implemented using the Comparator interface 45

46. Stated in very general terms, the idea is this: What sorting is doesn’t change What sort order you get depends on the objects you’re sorting What you begin to see is that with careful design and reliance on polymorphism, it is possible to write very flexible and general code That’s what the template pattern is about, and it doesn’t just apply to sorting 46

47. The book provides the UML diagram shown on the following overhead to summarize the Comparable and Comparator interfaces along with the Collections class The diagram would be more complete if it included the sort() method on the natural order along with the sort() method with the comparator parameter 47

48. 48

49. Next the book gives a concrete example of sorting based on objects in the fireworks set of classes The code constructs an array of rockets It then uses the sort() method of the Arrays class and a comparator named ApogeeComparator to sort the rockets It prints out the sorted array 49

50. Then it sorts the array again using a NameComparator object as the second parameter to the sort method It prints out the re-sorted array The code is shown on the following overheads 50

51. public class ShowComparator { public static void main(String args[]) { Rocket r1 = new Rocket("Sock-it", 0.8, new Dollars(11.95), 320, 25); Rocket r2 = new Rocket("Sprocket", 1.5, new Dollars(22.95), 270, 40); Rocket r3 = new Rocket("Mach-it", 1.1, new Dollars(22.95), 1000, 70); Rocket r4 = new Rocket("Pocket", 0.3, new Dollars(4.95), 150, 20); Rocket[] rockets = new Rocket[] { r1, r2, r3, r4 }; 51

52. System.out.println("Sorted by apogee: "); Arrays.sort(rockets, new ApogeeComparator()); for (int i = 0; i < rockets.length; i++) System.out.println(rockets[i]); System.out.println(); System.out.println("Sorted by name: "); Arrays.sort(rockets, new NameComparator()); for (int i = 0; i < rockets.length; i++) System.out.println(rockets[i]); } 52

53. The book gives the output shown on the following overhead for the program It’s clear that the toString() method for the Rocket class isn’t very complete It would be helpful if it showed the apogee values so that that sort could be verified 53

54. Sorted by apogee: Pocket Sprocket Sock-it Mach-it Sorted by name: Mach-it Pocket Sock-it sprocket 54

55. Clearly, how the code sorts is based on the template pattern In other words, everything depends on how the ApogeeComparator and NameComparator are implemented The book gives the partial code shown on the following overhead for these classes 55

56. public class ApogeeComparator implements Comparator { // Challenge! } public class NameComparator implements Comparator { // Challenge! } 56

57. Challenge 21.1 Fill in the missing code in the ApogeeComparator and NameComparator classes so that the program will sort a collection of rockets correctly. 57

58. Solution 21.1 Your completed program should look something like: [See the following overheads] 58

59. public class ApogeeComparator implements Comparator { public int compare(Object o1, Object o2) { Rocket r1 = (Rocket) o1; Rocket r2 = (Rocket) o2; return Double.compare(r1.getApogee(), r2.getApogee()); } 59

60. public class NameComparator implements Comparator { public int compare(Object o1, Object o2) { Rocket r1 = (Rocket) o1; Rocket r2 = (Rocket) o2; return r1.toString().compareTo(r2.toString()); } 60

61. The book reiterates the idea behind the Template pattern with this observation: Sorting, per se, doesn’t have anything to do with rocket apogees Rocket apogees are a problem domain specific concept It is extremely convenient to be able to implement sorting with a general algorithm that would apply to many things Then for each different type of thing, all you have to is provide the comparison step 61

62. Conclusion As pointed out at the beginning, the overhead presentation ends with the example taken from sorting The rest of the chapter will not be covered and you will not be responsible for it A subset of the book’s summary is given on the following overhead The rest of the diagrams for the chapter have been tipped in after that for future reference, but there is no need to look at them 62

63. Summary The intent of the Template Method design pattern is to define an algorithm in a method Some of the steps are left abstract, stubbed out, or defined in an interface Other classes then fill in the functionality for those missing steps 63

64. The Template Method design pattern can useful in a large scale development environment One developer is responsible for setting up the outline of an algorithm (like sorting for example) Then other developers only need to fill in the missing steps in order to use the general outline 64

65. The book also notes that the development of the Template Method pattern may go in the opposite direction You may find that you are repeating similar code in different places, where the only difference seems to be in certain small steps It would then be possible to refactor and generalize, taking the commonality out into a template 65

66. Elsewhere in the chapter the authors observe that there is some similarity between a template and an adapter In the end, all of the patterns start looking alike The idea here is that with a few well-designed interfaces it is possible for one piece of code (sorting for example) to make use of another (comparable objects) in order to achieve its overall goal 66

67. 67

68. 68

69. 69

70. The End 70