Summary prepared by Kirk Scott Unit 16 Template Summary prepared by Kirk Scott

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

The Introduction Before the Introduction In this chapter 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

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

If the overall algorithm is complex, this is a divide and conquer approach to code writing Whether the algorithm is complex or not, the pattern has another potential benefit The overall algorithm may be designed generally so that it can apply to multiple kinds of objects

The changes needed for specific kinds of objects can be implemented in the subparts The subparts could also be altered so that they accomplish something different, or in a different way, without chaning the overall outline of the algorithm

Book Definition of Pattern 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.

A Classic Example: Sorting 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

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

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

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

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

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 Just to try to make things clear from the outset, “natural order” is the order that will be defined by an implementation of the Comparable interface

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

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

compareTo()’s Return Values 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

The Arrays and Collections Classes 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

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.

The Arrays and Collections Classes Contain Static Methods 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

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

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.”

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

The sort() Methods in the Arrays Class 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

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

Sorting Arrays 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

Natural Order Sorting is Based on Implementing the Comparable Interface Here is part of the Java API documentation for that sort() method: public static void sort(Object[] a) 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.

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

Sorting Object References in Collections 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

Again, Natural Order Sorting is Based on Implementing the Comparable Interface Here is part of the Java API documentation for that sort() method: public static <T extends Comparable<? super T>> void sort(List<T> list) 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.

The signature of this sort() method differs from the signature of the sort() method in the Arrays class in two ways: 1. 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

2. 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

Aside from 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

Flexibility of the Template Pattern—Re-using the Comparison Operation 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

If you factor out the individual comparison operation, different sorting algorithms can rely on that In the Java supplied sorting methods, 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

Flexibility of the Template Pattern— Changing the Comparison Operation 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

Sorting in a Different Order with a Different Comparison Operation 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

The Comparator Interface for “Non-natural Order” Sorting 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

compare() isn’t declared static in the interface definition, but in a practical sense it is It takes two instances of a class as explicit parameter and compares them with each other Just like with compareTo(), we don’t call the method ourselves A sorting method that uses Comparator will call the compare() method

Return Values of compare() The meaning of the integer return value is the same as for compareTo(), 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

The results of compare() are not considered the natural order 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

The sort() Method with a Comparator Parameter in the Arrays Class Here is part of the Java API documentation for that sort() method in the Arrays class: public static <T> void sort(T[] a, Comparator<? super T> c) Sorts the specified array of objects according to the order induced by the specified comparator.

The sort() Method with a Comparator Parameter in the Collections Class Here is part of the Java API documentation for that sort() method in the Collections class: public static <T> void sort(List<T> list, Comparator<? super T> c) Sorts the specified list according to the order induced by the specified comparator.

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

Review of the Overall Idea 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

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 With careful design and reliance on polymorphism, it is possible to write flexible and general code That’s what the template pattern is about, and it doesn’t just apply to sorting

UML for the Pattern 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

The Book’s Concrete Example The book illustrates 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

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

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 };

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()); }

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

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

The Comparator Classes for the Example 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

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

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.

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

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()); }

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()); }

How the Example Illustrates the Pattern 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 do is provide the comparison step

Another Example No other example will be presented in class This overhead is just a reminder that an application of sorting the Cup and Seed classes is given in the Web directory of this unit

Lasater’s UML for the Pattern Lasater’s UML for the pattern is given on the following overhead Keep in mind that this is general, not specific to sorting The idea is that an operation may implement a general algorithm What the algorithm accomplishes depends on the specific operations implemented in the concrete subclass

UML for the Pattern On the following overhead I give a UML diagram where I attempt to summarize my understanding of the pattern. The Template class contains a method with a general implementation of an algorithm That implementation relies on calls to the specific “other” methods defined in the other classes

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

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

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

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

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

The End