You are here

Balls that change their strategies

15 January, 2016 - 09:02
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at

Let's consider a the notion of a ball that changes its behavior. Since we have modeled a ball as having a strategy, we can simply say that in some manner, it is the ball's strategy that changes. We could say that the ball changes its strategy, but since the ball doesn't know which strategy it has to begin with, it really doesn't know one strategy from another. One could argue that it therefore can't know when or if it should ever change its strategy. Therefore, the ball cannot be coded to change its own strategy! So, whose baliwick is the changing of the strategy?

Since the changing of a strategy is a strategy for updating the ball, it is the strategy that determines the change. The strategy changes the strategy! Let's consider the following strategy:

package ballworld; import java.awt.*; 

public class Change1Strategy implements IUpdateStrategy { 

private int i = 500; 11 initial value for i 

public void updateState(Ball context) {     if(i==0) context.setStrategy(new CurveStrategy()); 11 change strategy if i reaches zero     else i--; 11 not yet zero, so decrement i   } } 

This strategy acts just like a StraightStrategy for 500 updates and then it tells the ball (its context) to switch to a CurveStrategy. Once the CurveStrategy is installed, the ball becomes curving, without the need for any sort of conditionals to decide what it should do. The context ball fundamentally and permanently becomes curving.

Exercise 2.12

What would happen if you had two strategies like the one above, but instead of replacing themselves

with CurveStrategy's , they instead instantiated each other?

A key notion above is that a strategy can contain another strategy. In the above example, the Change1Strategy could have easily pre-instantiated the CurveStrategy and saved it in a field for use when it was needed. But the does it matter exactly which concrete strategy is being used? If not, why not work at a higher abstraction level and let one strategy hold a reference to an abstract strategy? For instance, consider the following code:

package ballworld; import java.awt.*; 

public class SwitcherStrategy implements IUpdateStrategy { 

    private IUpdateStrategy _strategy = new StraightStrategy(); 

    public void updateState(Ball context) {       _strategy.updateState(context);     } 

    public void setStrategy(IUpdateStrategy newStrategy) {       _strategy = newStrategy;     } } 

This strategy doesn't look like it does much, but looks are deceiving. All the SwitcherStrategy does is to delegate the updateState method to the _strategy that it holds. This does not seem much in of itself, but consider the fact that the SwitcherStrategy also has a settor method for _strategy. This means that the strategy held can be changed at run time! More importantly, suppose a ball is instantiated with a SwitcherStrategy. The behavior of the ball would be that of whatever strategy is being held by the SwitcherStrategy since the switcher just delegates to the held strategy. If one were to have a reference to that SwitcherStrategy instance from somewhere else, one could then change the internal strategy. The ball is none the wiser because all it has is a reference to the SwitcherStrategy instance, which hasn't changed at all! However, since the held strategy is now different, the ball's behavior has completely changed! This is an example of the Decorator Design Pattern, where the SwitcherStrategy class is formally called the decorator and the held strategy is formally called the decoree. In theoretical terms, the decorator is what is known as an indirection layer, which is like a buffer between two enities that enables them to depend on each other but yet still be free to move and change with respect to each other. A very useful analogy for indirection layers is like the thin layer of oil that will enable two sheets of metal to slide easily past each other.