Design Patterns discussion

[Wayne Cannon <wcannon AT sonic.net>]

Strategy can certainly change frequently, as the strategy for handling 
entries into an interactive tax preparation form might depend on values 
and or options selected in other parts of the form and changes 
dynamically as the user experiments with various approaches.  Similarly, 
the strategy for displaying graphic representations (e.g., maps) may 
change with degrees of zoom.

Although it seems like a perversion of the "finite state machine" intent 
of the State pattern, I guess I can see a State pattern as an approach 
to implementing the Strategy pattern.

It is important to keep in mind that they are not similar patterns.  One 
can be used as one approach to implementing the other -- i.e., the State 
pattern might be used as an approach to implementing the Strategy pattern.

The Strategy pattern does not specify how a particular Concrete Strategy 
is selected, or anything about the lifetime of Concrete Strategy 
objects.  The State pattern is all about how you select and switch 
between different Concrete State implementations of the State interface, 
and not about the purpose/use of the objects.  The State pattern can be 
used as the approach for selecting and switching between various 
Concrete Strategies.

On the other hand, the reverse relationship between Strategy and State 
patterns does not hold -- i.e., the Strategy pattern is not an approach 
to implementing the State pattern.

--Wayne

Peter Horan wrote:

> The difference is that in strategy, the selected strategy is usually 
> set from outside, and is unlikely to change, whereas in the state 
> pattern, the selected state object changes frequently as defined by 
> the state model in response to the current state and received events.