Design Patterns in Java Chapter 23 Strategy

1. Design Patterns in JavaChapter 23Strategy 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 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 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 booleanhasItem() • { • 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 PromotionAdvisorpromotionAdvisor = new PromotionAdvisor(); • private static GroupAdvisorgroupAdvisor = new GroupAdvisor(); • private static ItemAdvisoritemAdvisor = new ItemAdvisor(); • private static RandomAdvisorrandomAdvisor = 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. 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