State Vs Stratergy Pattern

[Farouk Mohamed1]

Hi
I always have a problem understanding the crucial difference between State and Strategy patterns. When I look at the implementations of both of these patterns i observe no stuctural and coding differences.
State Pattern According to me allows objects to be chosen on run time by the client. So changing objects is possible as and when the client requires a change in the state.
Strategy Pattern aswell allows to change the objects at runtime by the client. So changing objects is possible as and when the client requires a change in the strategy.
As you can see the only difference is only the type of objects Changed (State and Strategy).
Questions on this pattern?
1. Is my way of thinking about State and Strategy Patterns correct?
2. Why to have two different patterns for doing the same work , instead why cant I call it as Runtime object changing pattern which will cover the both the aspects of State and strategy pattern and make developers to imagine abstract situations.
3. If my view is incorrect please explain, your views?
Many Thanks
Farouk

[Alan Shalloway]

This is a common confusion. When looking at the implementations of state and strategy, they do look a lot alike. That is because both patterns have a context containing a variation. However, the best way to tell patterns apart is not by how they are implemented, nor even by their designs, but rather by their motivations. Let's look at the State pattern. You use it when you have a program that does different things at different times and when there are transitions between these different things. That is, the program has states, or is modal. An example of this would be a drawing program like Visio. When you click on an icon, the next time you click on your pad you will get the icon moved there. Other times, if you are in different states, clicking in the pad won't get you an icon. The state pattern gives you a way to manage the different states independently of each other. It allows you to break your problem down into:
1) your states
2) the rules for transitioning between your states
The strategy pattern is much simpler. It occurs when you have many different rules you might want to apply. In this case, you don't want the program using the rule to know which rule it is using. Instead, it is given the rule to use by the calling program. This enables you to add new rules without changing the using program.
The motivations are quite different. In the state pattern, you are trying to write your code on a per state basis to increase cohesion (clarity) of your code and to enable easier transitions. In the strategy pattern you are trying to make the use of rules independent from the rules themselves. This enables you to add new rules without affecting the user.
Both patterns take advantage of polymorphism. Polymorphism is when you have a handle to an object, but the handle is of an abstract class type or interface. The actual object you have is instantiated from any class derived from the abstract class (or any class that implements the interface). Thus, polymorphism encapsulate (hides) which type of object you have. Since the using object doesn't know what type it has, you can add new derivations or implementations.
I hope this has answered your questions, if not, please let me know.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.

[Farouk Mohamed1]

Hi Alan
I appreciate your reply,I think pattern is something reoccuring and from your explantions i understand that pattern means problem patterns.
After reading design patterns from different authors with different interpretations I started to think exactly in the the opposite direction (i.e. patterns means solution patterns or implementation patterns).
***********************************************
Because learning patterns have become a Problem
***********************************************
Thats why i looked at State and Strategy patterns from their implementation point of view (Solution) and realised they solve similiar kind of PROBLEM(Changing objects at runtime(COAR)).
So COAR is a level of abstraction and if you look at this view point on State and Strategy they are a specialized versions of COAR patterns.
I would prefer reading books based on design patterns if they are describing or explaining patterns based on abstraction and
specializations which will highlight differences between patterns easily than treating each pattern as a separate entity.
**************************************************************
I believe human mind learns better by comparing things than by looking at a thing as a whole
*****************************
Questions?
1. What do you think of my solution patterns and abtractions based on it?
2.Is your book deal with explaining patterns individually or
in really a different perspective explaining abstractions and variantions between patterns which other book doesn't?
3.Have you described this difference, you said about Strategy being similiar to State and doing less work than State in your book.?
Awaiting Reply
Farouk

[Alan Shalloway]

Before I forget, there is a writeup of the state pattern on our site at: http://www.netobjectives.com/dpexplained/download/state_pattern.pdf
This is an excerpt from our course: Pattern Oriented Design: Design Patterns From Analysis to Implementation, and is intended to support my discussions, but I think it is somewhat understandable on its own.
Regarding your questions:
>> 1. What do you think of my solution patterns and abtractions based on it?
I think patterns need to be looked at all angles. They are really holistic in that sense. They:
1) describe a problem within a particular context and why you would want to solve it
2) they describe an approach to a solution (the core to the solution) as well as the forces you must attend to.
3) they live in analysis, design and implementation.
>> 2.Is your book deal with explaining patterns individually or
in really a different perspective explaining abstractions and variantions between patterns which other book doesn't?
We do describe individual patterns, but it is with the intention of explaining the abstractions and variations between the patterns. We are trying to get at why the patterns work, not just what they are.
>> 3.Have you described this difference, you said about Strategy being similiar to State and doing less work than State in your book.?
We don't talk about this difference in the book because we don't get to the state pattern in the book (only the strategy pattern). We do talk about the differences between the patterns a lot more in the course.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Kyle Brown]

Originally posted by Farouk Mohamed1:
Hi
I always have a problem understanding the crucial difference between State and Strategy patterns. When I look at the implementations of both of these patterns i observe no stuctural and coding differences.
State Pattern According to me allows objects to be chosen on run time by the client. So changing objects is possible as and when the client requires a change in the state.
Strategy Pattern aswell allows to change the objects at runtime by the client. So changing objects is possible as and when the client requires a change in the strategy.
As you can see the only difference is only the type of objects Changed (State and Strategy).
Questions on this pattern?
1. Is my way of thinking about State and Strategy Patterns correct?
2. Why to have two different patterns for doing the same work , instead why cant I call it as Runtime object changing pattern which will cover the both the aspects of State and strategy pattern and make developers to imagine abstract situations.
3. If my view is incorrect please explain, your views?
Many Thanks
Farouk

I discussed the difference between the two in my book "The Design Patterns Smalltalk Companion" several years ago. Here's the relevent section:

State vs. Strategy
State is often confused with its close cousin Strategy, and it is sometimes difficult to determine which pattern to use, or if an implementation of one is actually the other. A good rule of thumb to follow to distinguish the two is that if the Context will contain only one (of several possible) �State� or �Strategy� objects during its lifetime, you are probably using the Strategy pattern. If, on the other hand, the Context changes during the normal course of an application so that, over time, it may contain many different �state� objects , then you may be referring to a State implementation, particularly if there are well-defined orders of transition between the different states. A subtler distinction
can sometimes be found in the setting of an object�s attributes. An object is usually put into a state by an external client, while it will choose a strategy on its own.
Another distinction is that a Context seems to hide the Strategy it�s using, but the State it�s using is quite apparent to its Client. For example, when a Client tells a Storage-Device to store some text, the device may use one of several different techniques to compress the text before storing it, including no compression at all. However, the Client doesn�t care how the device compresses the text, whether it does so at all, or whether it compresses the text the same way every time. It just wants the device to store and retrieve the text on command. Because of the way the compression is private to the device and hidden from the Client, the different compression objects are Strategies. On the other hand, once a Client opens a TCPConnection, it certainly expects the connection to behave like it�s open. Once the Client closes the connection, it expected the connected to act like it�s closed. Because the connection�s status is readily apparent to the Client, the status objects are States.
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
[This message has been edited by Kyle Brown (edited October 02, 2001).]

[Farouk Mohamed1]

Hi Alan
Thanks for your time and your valuable explaination.
I am able to get the things much clearer.
I will read the book soon
Many Thanks
Farouk

[Farouk Mohamed1]

Hi Kyle
Thanks for the excellent explanation you did about these two patterns.
Now i understand the crux of it and its importance on the context of usage.
Question.
1. When you say the device hides the implemenation of different strategies of text Compression from the client, and client has no say on i would say the device is playing the role of something like a state machine having different strategies in it.
Do you not think so , i was of the view in both the state and strategy the client has control to change the object on the fly.
Your comments please on
1. Device comparison with state Machine
2. Client's control on the strategy to choose
Many Thanks
Faoruk

[Kyle Brown]

Originally posted by Farouk Mohamed1:
Hi Kyle
Thanks for the excellent explanation you did about these two patterns.
Now i understand the crux of it and its importance on the context of usage.
Question.
1. When you say the device hides the implemenation of different strategies of text Compression from the client, and client has no say on i would say the device is playing the role of something like a state machine having different strategies in it.
Do you not think so , i was of the view in both the state and strategy the client has control to change the object on the fly.
Your comments please on
1. Device comparison with state Machine
2. Client's control on the strategy to choose
Many Thanks
Faoruk

Quite good questions, Faoruk. Now, I would say that the example of the storage device that stores text that the problem is that there is no explicit state machine. You don't transit from "zip" to "none" in a meaningful way. There probably aren't side effects of changing the compression option. Both of them (explicit transitions and side-effects) are probably needed to really be an implementation of state.
In strategy -- the client isn't the one in charge -- that's the context. The client MAY set the strategy, but that's probably exposing too many details of the implementation to the client. Instead the object using the strategy usually sets it based on some internal algorithm that may bring in a number of factors. For instance, to decide whether or not to use compression, it may refer to an external configuration parameter. Or, it may keep track of the disk space and "switch" to compression when it meets some threshold. As you can see, the clients (Files and Directories) probably won't make that decision, but the storage device would make it for all of them...

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere

[Farouk Mohamed1]

Hi Kyle
Thanks again for your explicit explanation.
Let me summarize what I learnt out of this comparitive Analysis
State Vs Strategy Vs StateMachine:
State pattern lets the client take in charge and command the context to use a specific object(State) on the runtime.
Stratergy pattern lets the client sometimes advice and the context will determine on the fly what strategy to use based on
some algorithm
StateMachine is comparable to Strategy but state machine pattern is evident if there is explicit state transitions and possible side effects because of those transitions.
Please correct me if i missed something
Thanks again
Farouk