1. Strategy Design Pattern
COSC3311 – Software Design
Strategy Design Pattern

2. (c) Head First Design Patterns chapter 1

3. Someone has already solved your problem
Exploit the wisdom and lessons learned by other developers who’ve been down the same design problem road and survived the trip.
Instead of code reuse, with patterns you get experience reuse.

4. Joe’s problem: SimUDuck

5. superclass DUCK

6. In the last year, the company has been under increasing pressure from competitors.
After a week long off-site brainstorming session over golf, the company executives think it’s time for a big innovation.
They need something really impressive to show at the
upcoming shareholders meeting in Maui next week.

13. What do you think about this design?
Java interface

14. We know that not all of the subclasses should have flying or quacking behavior, so inheritance isn’t the right answer.
But a Java interface has no implementation – so we have now destroyed code reuse
What about Eiffel?
Not a problem because we have full support for multiple inheritance

15. Problem: Find a design?
Most ducks fly in the same way, but a few species of duck have different flyable behaviour, or perhaps they do not fly at all
Most ducks quack in the same way, but a few species have a different quackable behaviour or they do not quack at all
Must be able to change flyable and quackable behavior dynamically

17. Okay, what’s the one thing you can always count on in software development?
No matter where you work, what you’re building, or what language you are programming in, what’s the one true constant that will be with you always?

18. The one constant
No matter how well you design an application, over time an application must grow and change or it will die.

20. Inheritance hasn’t worked out very well, since the duck behavior keeps changing across the subclasses, and it’s not appropriate for all subclasses to have those behaviors.
The Flyable and Quackable interface sounded promising at first—only ducks that really do fly will be Flyable, etc.—except Java interfaces have no implementation code, so no code reuse.
And that means that whenever you need to modify a behavior, you’re forced to track down and change it in all the different subclasses where that behavior is defined, probably introducing new bugs along the way!

21. Design Principle
take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t
Identify the aspects of your
application that vary and separate
them from what stays the same.

23. We’d like to keep things flexible
We’d like to keep things flexible. It was the inflexibility in the duck behaviors that got us into trouble in the first place.
And we know that we want to assign behaviors to the instances of Duck.
For example, we might want to instantiate a new MallardDuck instance and initialize it with a specific type of flying behavior.
And while we’re there, why not make sure that we can change the behavior of a duck dynamically?

24. Design Principle Program to an interface not to an implementation
Duck behaviours (e.g. flying, quacking) will live in a class that is separate from class DUCK.
DUCK does not need to know how those behaviours are implemented

25. Not a Java “interface” The word “interface” is overloaded
Here we do not mean a Java interface – rather we mean the concept of an interface
Programming to an implementation
list: LINKED_LIST[PERSON]
Programming to an interface (supertype)
list: LIST[PERSON]
create {LINKED_LIST[PERSON]}list.make

26. Delegation

27. Has-a
Is-a

28. Question? Should we make DUCK an <<interface>> as well?
Not in this case.
Duck can be abstract and some descendants like MALLARD_DUCK inherit common properties and methods.
Now that we’ve removed what varies from the Duck inheritance, we get the benefits of this structure without the problems.

29. Question?
Using our new design, what would you do if you needed to add rocket-powered flying to the SimUDuck app?
class
ROCKET_POWERED_DUCK
inherit
FLY_BEHAVIOUR

30. Program to an interface not to an implementation

31. MALLARD_DUCK?

32. Good catch, that’s exactly what we’re doing. for now
Good catch, that’s exactly what we’re doing... for now. [Other creator patterns can help]
Still, notice that while we are setting the behaviors to concrete classes Quack or FlyWithWings, but we are assigning it to our behavior reference variable, and that could easily change at runtime.
How? [see in a few slides]

33. class DUCK

37. Setting behavior dynamically

41. Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.
Strategy lets the algorithm vary independently from clients that use it.
use this definition when you want impress friends & influence key executives

42. Patterns give developers a shared vocabulary as well as a shared code experience