Lecture 3: Strategy Pattern –or– Bringing a Knife to a Gunfight

1. CSC 313 – Advanced Programming Topics Lecture 3:Strategy Pattern –or–Bringing a Knife to a Gunfight

2. Bested by Lilliputians

3. Bested by Lilliputians

4. Bested by Lilliputians quack behavior fly behavior

5. Bested by Lilliputians quack behavior fly behavior • Lot of short ones beats a big, tall one

6. Implementing a Strategy public interface FlyBehavior {public void fly(); } public class UseJets implements FlyBehavior {public void fly() {System.out.println(“Vrooom”);} } public class Wings implements FlyBehavior {public void fly() {System.out.println(“Band On the Run”);} }

7. Implementing a Strategy public interface FlyBehavior {public void fly(); } public class UseJets implements FlyBehavior {public void fly() {System.out.println(“Vrooom”);} } public class Wings implements FlyBehavior {public void fly() {System.out.println(“Band On the Run”);} }

8. Using a Strategy public interface FlyBehavior {public void fly(); } public abstractclass Duck {private FlyBehaviorflyBehavior;public Duck(FlyBehaviorf) { flyBehavior = f; }public void fly() { flyBehavior.fly(); } } public class PaulMcCartney extends Duck {public PaulMcCartney() { super(new Wings()); } } public class DecoyDuck extends Duck {public DecoyDuck() { super(newNoFly()); } }

9. Strategy Pattern • Define supertype for family of algorithms • interface used nearly always for this • Entire family relies on method signature specified • Make algorithms interchangeable • Separate class encapsulates each algorithm • Algorithm definition split from its use • Add algorithms easily with no changes to code • New environments can also reuse algorithms

10. Zen & the Art of Programming Identify and isolate what will change from what stays the same • What is being done split from how to do it Program to a concept, not a class • Client cannot know what Strategy does • Strategy limited to working only with parameters

11. Changing your Strategy • Strategy fixed only when client calls it • Determined by value of field when the call is made • Set & change strategies at any time • Client does not know implementation to rely on it • Simply reassign field whenever it should change • All the Client subclasses may not be needed • If only Strategy differs, just change field’s value • At worst, subclasses limited to a constructor

12. Reusing a Strategy public class JetFighter {private FlyBehaviorflyBehavior;public JetFighter() {flyBehavior = new UseJets();}public void fly() { flyBehavior.fly();} }

13. Reusing a Strategy public class JetFighter {private FlyBehaviorflyBehavior;public JetFighter() {flyBehavior = new UseJets();}public void fly() {flyBehavior.fly();} } Thanks to the Strategy Pattern, I had more time for FarmVille!

14. Zen & Art of Programming Favor composition over inheritance • Composition is far easier to spell

15. Tools: Are They Worth It? • Good in correct environments & for correct uses

16. Tools: Are They Worth It? • Good in correct environments & for correct uses • Become an abomination in other situations

17. Tools: Are They Worth It? • Good in correct environments & for correct uses • Become an abomination in other situations

18. Making Tools Work • Use inheritance… • …to have class expand concepts in superclass • …not add or modify behavior that is inherited • Use Strategy Pattern… • …for single concept with multiple behaviors

19. Zen & the Art of Programming Favor composition over inheritance • Inheritance has problems • Specify when written;cannot change dynamically • Limits use & re-use of classes to original concept • Makes adding & mixing functionality difficult • Composition imperfect also • Can make debugging more difficult • Requires more classes & interfaces to work • With composition, optimizations may not occur

20. For Next Lecture • Read pages 26 - 32 • How do you talk about a program? • What do you write in your documentation? • What do wish others documentation would say? • What makes for good design? • Ever seen beautiful code? What made it pretty?