Strategy vs. State

[paul wheaton]

I recently had an opportunity to attend an excellent presentation by Craig Larman called "Fast Java Fast". I was the obnoxious guy sitting in the front asking too many questions. Afterwards, Craig asked me what I thought of the presentation (How cool is that!?)
At one point I said something about how I was confused when he mentioned a state pattern, but the implementation looked like a strategy pattern to me. Since he has authored a book on patterns, I must be wrong. His explanation still didn't seem to fix things in my head.
Without giving away (yet) what I think the difference is and what Mr. Larman thinks the difference is, I would like to gather some un-biased feedback from others on what the difference is.
Anybody?

[John Wetherbie]

Hmm...
Well the way I see it and have done it is that I use State when I want the object to act like an FSM. A message may cause a state transition (or not) which causes the object to do something or to react differently when a new message arrives. Strategy is more static in that you figure out what algorithm to apply and you use that one. Of course, you could make Strategy look like State in the sense that as different types of messages come in you select the best algorithm to handle them.
You were probably hoping for a short answer, weren't you...
John

[Linda Rising]

Originally posted by Paul Wheaton:
I recently had an opportunity to attend an excellent presentation by Craig Larman called "Fast Java Fast". I was the obnoxious guy sitting in the front asking too many questions. Afterwards, Craig asked me what I thought of the presentation (How cool is that!?)
At one point I said something about how I was confused when he mentioned a state pattern, but the implementation looked like a strategy pattern to me. Since he has authored a book on patterns, I must be wrong. His explanation still didn't seem to fix things in my head.
Without giving away (yet) what I think the difference is and what Mr. Larman thinks the difference is, I would like to gather some un-biased feedback from others on what the difference is.
Anybody?

Hi,
You point out a big problem with patterns -- it's easy to get them confused! Many patterns can be represented with diagrams that look exactly like diagrams of other patterns -- even a text description of the text sounds almost the same! The answer for a GoF pattern is tricky since the GoF authors were on the scene before it was obvious that to describe a pattern you must include the problem that the pattern solves. Perhaps the GoF patterns need to be "refactored" :-)!
So what problems do State and Strategy solve? State might be easier -- the problem has to do with a change in behavior of an object directly related to a change in the state of the object. When the state of the object changes the state must also change. So what problem is solved by Strategy? Yes, there is a change in behavior but not necessary related to an object with state -- typically Strategy solves the problem of a changing algorithm and a decision-maker somewhere in the system initiates the change (hidden from the client). A object with state is not involved.
We recently had this discussion in the Denmark patterns group because the presenter of the pattern that particular evening was talking about Strategy and the example he used was really an example of State :-)! It made for an interesting learning experience, though, as study groups do!!
The Pattern Alamanc is a great way of having summaries of patterns to help you when things get fuzzy! Get a free copy this week and enjoy!
Linda

------------------
Linda Rising
Author of The Pattern Almanac 2000

[Guennadiy VANIN]

Originally posted by Linda Rising:
When the state of the object changes the state must also change. So what problem is solved by Strategy? Yes, there is a change in behavior but not necessary related to an object with state -- typically Strategy solves the problem of a changing algorithm and a decision-maker somewhere in the system initiates the change (hidden from the client).

I couldn't understand: "state" vs. "state of the object". What are its definitions?
What is "algorithm" vs. "behavior". And how it is changed outside of objects?
[ January 17, 2003: Message edited by: yidanneuG ninaV ]

[Ajith Kallambella]

My two cents worth....
I have implemented strategy for sorting algorithms. Based on the complexity of sorting required( quantified on a numeric scale ), our presentation layer logic dynamically selects one sorting algorithm out of many available. Since all sorting algorithms implement a common interface, the calling code remains transparent to complex selection that happens behind the screen.
I have also implemented state for configurable workflow components. Instead of an object state being an attribute( string, code, int values etc ), it is represented as a firstclass entity. Each state instance "knows" its context in the workflow and hence can smartly figure out what the next state will be. However, I have heard a lot of arguments against this approach since many feel this will introduce extra objects that merely encapsulate an enumeration of states.

[Michael Matola]

Hope I'm not misrepresenting Martin Fowler, but throughout his Refactoring book he blurs the/any distinction between the two and usually refers to the pattern as "state/strategy." According to him, I believe, the distinction is in the intent of the pattern and not the implementation.

[Roshan Lal]

I have been confused on this too! Structurally the look same. Now, I think, and I may be very wrong, the main difference is in usage. In State, it must have interesting states. In Strategy, the object may not have any intesting state it can be more of a performer.
In State, the state is not changed by client explicitely i.e., setNewState(someState) is not called by the client the object itself changes its state.
In Strategy, a client can call setNewStrategy(newStategy) directly.

My 2 cents
-Roshan

Originally posted by Paul Wheaton:
I recently had an opportunity to attend an excellent presentation by Craig Larman called "Fast Java Fast". I was the obnoxious guy sitting in the front asking too many questions. Afterwards, Craig asked me what I thought of the presentation (How cool is that!?)
At one point I said something about how I was confused when he mentioned a state pattern, but the implementation looked like a strategy pattern to me. Since he has authored a book on patterns, I must be wrong. His explanation still didn't seem to fix things in my head.
Without giving away (yet) what I think the difference is and what Mr. Larman thinks the difference is, I would like to gather some un-biased feedback from others on what the difference is.
Anybody?

[Ilja Preuss]

Originally posted by yidanneuG ninaV:
I couldn't understand: "state" vs. "state of the object". What are its definitions?

I think Linda meant the "state object" (of the State pattern) vs. "state of the object" as represented by the values of its instance variables.

What is "algorithm" vs. "behavior". And how it is changed outside of objects?

The behaviour of an object (that is, what the object is doing) can be polymorphically configured by passing a "strategy object" into it.
You should probably take a closer look at the two design patterns for a better understanding.
[ January 22, 2003: Message edited by: Ilja Preuss ]

[Guennadiy VANIN]

Thanks a lot, Ilja

[Alex Garrett]

Here's how I understand it:
State:
You have a GUI with a button on it. The first time you press the button, it beeps. The second time you press the button the dialog box flashes, the third time it erases your hard drive.
Strategy:
You have a GUI with a button on it. The first time you press the button, it beeps. The second time you press the button the dialog box flashes, the third time it checks to see what kind of file system you are using, instantiates the appropriate file deletion strategy, and erases your hard drive.
Strategy has one problem (erasing a hard drive) and many different solutions. State is a way of encapsulating different behaviours behind a uniform interface. In this case, the button would be coupled to a state object that would change each time the button is pressed.
Does that make sense?

[Roshan Lal]

Yes, it does make sense. Only thing I want to add is that object containing abstratct strategy may not itself decide to choose appropriate concrete strategy, rather the appropriate strategy can be directly set by its client.
That is the distinction I got from reading some article. (I forgot the article source).

... the third time it checks to see what kind of file system you are using, instantiates the appropriate file deletion strategy, and erases your hard drive.
Strategy has one problem (erasing a hard drive) and many different solutions. State is a way of encapsulating different behaviours behind a uniform interface. In this case, the button would be coupled to a state object that would change each time the button is pressed.
Does that make sense?

[Saurabh Banerjee]

I think of state as a special case of strategy where the state drives the algorithm.