1. Design Patterns in Java Chapter 23 Strategy
Summary prepared by Kirk Scott

2. In general, a single strategy might be thought of as an algorithm or an operation
In the context of the Strategy design pattern, the idea is that there multiple approaches to doing something, depending on certain conditions or context
Strategy, then, depends on picking the approach or picking the strategy

3. When there is more than one way to go about doing something, complexity can result
Not only are there the different implementations to consider
There is also the code that is devoted to making the choice of which strategy to use

4. The purpose of the Strategy design pattern is to separate the implementations of different strategies from each other
It is also to separate the code for picking the strategy from the strategy implementations
The Strategy design pattern accomplishes this by defining a single interface for all strategies and putting the implementations for different strategies into different classes

5. As you can tell from the previous description, the Strategy design pattern is another one where the intent is realized through an interface
Which strategy is used will depend on what kind of object the method implementing the strategy is called on

6. Book definition:
The intent of Strategy is to encapsulate alternative approaches, or strategies, in separate classes that each implement a common operation.

7. Modeling Strategies
Like with the previous chapters, and others, the book illustrates the Strategy design pattern in the following way:
It develops an example with multiple strategies that doesn’t use the Strategy design pattern
It then refactors the example using the Strategy design pattern

8. The scenario for the example works like this:
When a potential customer calls in, interested in buying fireworks, there is software which will make a recommendation or suggestion
There are several different ways a recommendation can be made:
Either a particular firework is being promoted, or two pieces of software, Rel8 or LikeMyStuff can make a recommendation, or a default option can be chosen

9. Rel8 relies on a customer’s already being registered
During registration the customer specifies preferences in entertainment and fireworks
Rel8 makes a suggestion based on the similarity of the customer to other customers (presumably suggesting something that similar customers have tended to buy)
If the customer isn’t registered, Rel8 can’t be used

10. LikeMyStuff doesn’t rely on pre-registration, but it does rely on customer information
The idea is that it will make a recommendation based on a profile of recent purchases by the customer
If not enough data can be obtained to form the profile, then LikeMyStuff can’t be used

11. This is the default:
If none of the previous options applies, then a firework is suggested at random

12. The UML diagram on the following overhead shows the classes involved in the design as described so far
Appendix D on UML clarifies the notation:
“Use a dashed arrow between class to show a dependency that does not use an object reference. For example, the Customer class relies on a static method from the LikeMyStuff recommendation engine.”

14. Viewing the scenario from the top down, what you have is this:
The Customer class has a getRecommended() method in it
This method consists of if/else code which chooses one of the strategies, whether to do a promotion, or to use Rel8, LikeMyStuff, or the default

15. The logic for doing a promotion consists of looking up the contents of a file named strategy.dat in a directory named config
If there is such a file, its contents should look something like this: promote=JSquirrel
The basic idea is that if the data file is not empty, the firework it contains is returned
If its contents come up null you go on to the next option
Also, if the file read doesn’t work, you don’t do anything in the catch block, you just continue on to the other options

16. The call looks like this:
The Rel8 class has a method advise(), so getRecommended() wraps a call to that method if that strategy is selected
The call looks like this:
if(isRegistered())
return (Firework) Rel8.advise(this);
“this” is the customer, and Rel8 relies entirely on the information contained in the registered customer object

17. The call looks like this:
The LikeMyStuff class has a suggest() method, so getRecommended wraps a call to that method if that strategy is selected
The call looks like this:
if(spendingSince(cal.getTime()) > 1000)
return (Firework) LikeMyStuff.suggest(this);
“this” is the customer, and LikeMyStuff relies on a database of recent purchases by that customer, which is accessed by the call to spendingSince() on the customer

18. The Firework class has a getRandom() method, so if all else fails, getRecommended() wraps a call to that method
The code is shown on the following overheads

19. public Firework getRecommended(){
// if promoting a particular firework, return it
try
Properties p = new Properties();
p.load(ClassLoader.getSystemResourceAsStream(“config/strategy.dat”));
String promotedName = p.getProperty(“promote”);
if(promotedName != null)
Firework f = Firework.lookup(promotedName);
if(f != null)
return f; }

20. catch(Exception ignored){
// If resource is missing or it failed to load,
// fall through to the next approach. }
// if registered, compare to other customers
if(isRegistered())
return (Firework) Rel8.advise(this);

21. // check spending over the last year
Calendar cal = Calendar.getInstance();
cal.add(Calendar.YEAR, -1);
if(spendingSince(cal.getTime()) > 1000)
return (Firework) LikeMyStuff.suggest(this);
// oh well!
return Firework.getRandom(); }

22. Refactoring to Strategy
The book identifies two basic problems with the getRecommended() method as given:
It’s too long
It combines both selecting a strategy and executing it

23. This is actually one of the high points of the book
It explains that you know that the method is too long because you need to put comments in it
“Short methods are easy to understand, seldom need explanation…”
Finally, what every student always knew: Comments are bad…

24. Anyway, applying the Strategy design pattern to the example involves three things:
Create an interface that defines the strategic operation
Implement the interface with classes that represent each strategy
Refactor the code to select and use an instance of the right strategy class

25. The interface will be named Advisor
It will specify that an implementing class have a method with these characteristics:
It will be named recommend()
It will take a customer as a parameter
It will return a firework
A UML diagram of the interface is given on the next overhead

27. The next step is to create the classes that represent the different strategies and implement the interface
The book essentially presents this information as part of the following challenge

28. Challenge 23.1
Fill in the class diagram in Figure 23.3, which shows the recommendation logic refactored into a collection of strategy classes.
Comment mode on:
What they want is mindlessly simple
That will be clear when you see the answer

30. Solution 23.1
Figure B.24 shows one solution.

32. In the previous diagram, the PromotionAdvisor and RandomAdvisor class names are self-explanatory
GroupAdvisor refers to the use of Rel8
ItemAdvisor refers to the use of LikeMyStuff
The implementations of the recommend() method for these classes is still just a wrapped call to the static methods of Rel8 and LikeMyStuff
An expanded UML diagram for these classes is given on the next overhead

34. The book notes that instances of GroupAdvisor and ItemAdvisor will be needed
An interface can’t define static methods
An interface defines what the book calls “object methods”, so instances of classes that implement an interface are needed in order to call the methods defined in the interface
Only one instance each of GroupAdvisor and ItemAdvisor are needed in order to call the desired method, and in the book’s new design, these instances will be static objects in the Customer class

35. This is what the recommend() method looks like in the GroupAdvisor class:
public Firework recommend(Customer c) {
return (Firework) Rel8.advise(c); }
By wrapping a call, recommend() in effect translates from the advise() interface of Rel8 to the recommend() interface of Advisor

36. Challenge 23.2
In addition to Strategy, what pattern appears in the GroupAdvisor and ItemAdvisor classes?

37. Solution 23.2
The GroupAdvisor and ItemAdvisor classes are instances of Adapter, providing the interface a client expects, using the services of a class with a different interface.
Comment mode on:
This wasn’t so hard—describing the wrapping of the call as “translating” kind of gave it away

38. A PromotionAdvisor class is also needed, with a recommend() method
Most of the logic of the original code is moved into the constructor for the new class
If a promotion is on, then the promoted instance variable of the class is intialized
In addition to the recommend() method, there is a hasItem() method which can be called to see whether a promoted item is available
The code is shown on the following overheads

39. public class PromotionAdvisor implements Advisor{
private Firework promoted;
public PromotionAdvisor()
try
Properties p = new Properties();
p.load(ClassLoader.getSystemResourceAsStream("config/strategy.dat"));
String promotedFireworkName = p.getProperty("promote");
if (promotedFireworkName != null)
promoted = Firework.lookup(promotedFireworkName); }
catch (Exception ignored)
// Resource not found or failed to load
promoted = null;

40. public boolean hasItem(){
return promoted != null; }
public Firework recommend(Customer c)
return promoted;

41. The RandomAdvisor class is simple
Its code is shown on the following overhead

42. public class RandomAdvisor implements Advisor{
public Firework recommend(Customer c)
return Firework.getRandom(); }

43. The new customer class, Customer2, has these lines of code in it:
private static PromotionAdvisor promotionAdvisor = new PromotionAdvisor();
private static GroupAdvisor groupAdvisor = new GroupAdvisor();
private static ItemAdvisor itemAdvisor = new ItemAdvisor();
private static RandomAdvisor randomAdvisor = new RandomAdvisor();
In order to make use of a recommend() method, a single instance of each of the advisor classes may be needed
The remaining logic that is needed is picking which kind of advisor to use

44. Customer2 also has the method getAdvisor() in it, shown on the next overhead
The book refers to the logic of this method as lazy-initialization
The objects have already been created, so it’s not lazy construction, but the value of the advisor instance variable for a customer is only set at the time that you try to acquire an advisor

45. private Advisor getAdvisor(){
if (advisor == null)
if (promotionAdvisor.hasItem())
advisor = promotionAdvisor;
else if (isRegistered())
advisor = groupAdvisor;
else if (isBigSpender())
advisor = itemAdvisor;
else
advisor = randomAdvisor; }
return advisor;

46. Challenge 23.3
Write the new code for Customer.getRecommended().
Comment mode on:
In other words, write the code for the new getRecommended() method in the Customer2 class
This code should rely on the advisor for the customer, and a call to the recommend() method on that advisor

47. Your code should look something like:
Solution 23.3
Your code should look something like:
public Firework getRecommended() {
return getAdvisor().recommend(this); }

48. Comparing Strategy and State
Recall the State design pattern example
It ended with a touch() method implemented in several different state classes
Now compare with the Strategy design pattern example
It ended with a recommend() method implemented in several different advisor classes
Which version of the method was called depended on polymorphism, the type of the object it was called on

49. It is possible to argue that there is little difference between the State and Strategy design patterns
Structurally, at least, this is the case
This has also been apparent with some of the patterns already considered
You could draw a UML diagram of the relationships between classes and two patterns would appear to be the same

50. As usual, the book argues that the critical difference is that states and strategies have different intents
Surely, it’s clear from the problem domains that there is a difference between transitioning between states of doors and choosing among fireworks to recommend
The difference isn’t just one of intent

51. The point of the touch() method was that calling it in one state caused you to enter another
Calling the recommend() method on a GroupAdvisor object didn’t somehow send the application into a state where the ItemAdvisor was now appropriate

52. Another way of seeing this is that in some applications it may be possible for the client to choose among several different available strategies
By definition, when doing state, the client doesn’t choose
The logic of the states themselves control the transition from one to another
All in all, the book concludes that in spite of their structural similarity, State and Strategy are different

53. Comparing Strategy and Template Method
Recall the first Template Method design pattern example
The template was a sort() method in the Arrays or Collections class
What was stubbed in was the pairwise comparison operation for elements of the data structure

54. The authors state that you might argue that changing the pairwise comparison step changes the strategy of sorting
They illustrate this idea by suggesting that sorting rockets by price rather than by thrust would support a different marketing strategy
Observe that the claim about strategy in this argument is about something in the problem domain, marketing, not in the code writing

55. Challenge 23.4
Provide and argument that the Arrays.sort() method provides an example of Template Method or that it is an example of Strategy.

56. Solution 23.4
Is a reusable sort routine an example of Template Method or of Strategy?
Comment mode on:
It’s clear what the book thinks since it put sorting in the Template Method chapter
I agree with its reasoning
See the answers on the following overheads

57. For Strategy
Template Method, according to the original Design Patterns book, lets “subclasses” redefine certain steps of an algorithm.
But the Collections.sort() method doesn’t work with subclasses; it uses a Comparator instance.
Each instance of Comparator provides a new method and thus a new algorithm and a new strategy.
The sort() method is a good example of Strategy.

58. For Template Method
There are many sorting algorithms, but Collections.sort() uses only one (QuickSort).
Changing the algorithm would mean changing to, say, a heap sort or a bubble sort.
The intent of Strategy is to let you plug in different algorithms.
That doesn’t happen here.
The intent of Template Method is to let you plug a step into an algorithm.
That is precisely how the sort() method works.

59. Summary Multiple strategies may appear in a single method
This can be an unwieldy design
A solution is to implement each separate strategy as a method of the same name in different classes
The individual implementations will be simpler

60. The original design would have logic to pick one of the strategies
The new design would also contain such logic somewhere, but at least it is separated from the implementations of the strategies
The new logic will be based on which of the strategy classes is constructed
It would be reasonable to hold the strategy object as a reference in a client class

61. Then at the appropriate time, this object has the strategy method called on it
In other words, once the object choice is made, the method choice is accomplished by polymorphism
The result of this kind of design is individual pieces of code that are smaller, simpler, and unified in purpose
Overall, the design should be clearer, with different strategies implemented in different classes

62. The End