Almost every software has state machines, It's one of those basic elements of the program. Different states of an object corresponding to different behaviors of it. The simplest state machine is likely the combination of if/else statements or switch/case statements within one class, like:

if( stateA )
{
 doSomething();
 flag = True;
}
else if( stateB )
{
 doSomething();
 flag = False;
}
else if( stateC )
{
 doNothing();
 firstTime = false;
}

It works! Absolutely! But what if we have 10 "flag" and 20 "firstTime"?? Then I guess compiler will be the only one that know how to add or modify a state. It will even be a nightmare if someone want to reuse the code! I can imagine that(Oh, noooooooooo...)

So, obviously we need a smarter way to write better designed, more extendable code to change our programming life. Then reusing the statemachine or adding a new state could be a piece of cake ;D.

Here's an example of this, assue we need to implement a file processing system, the system could write data to a file. So, we simply have 2 states in all.

The class diagram is (you can refer to the example code to know the implementation details):

In the program, I taked advantage of Symbian active object mechanism because active object is designed for asynchronous operations. You can see that every single state has it's own class, in each class, it implements all operations that possible or maynot possible to be invoked in this state. It will force you to think all the situations when transferring the state. For example, what's the behavior if the user wants to write some data to a file, when the system is busy, etc. The current solution discards the data and display an error message. In the real project, you can maintain a queue or something to save the operations and do it later.

You may say the state pattern looks cool, but it's ok if I don't use it according to the example above. You're right, but...

Requirement changes... Now your boss want to porting the existing file processing program to another platform which lack of hardware resource, say, your refrigerator(why the hell a refrigerator needs file system???But it's life, isn't it?) The limitation will be everytime I write data to a file, the max length of the data is 10 bytes. Meaning if I want to write 1KB data to a file, I have to write more than 100 times, what a stupid refrigerator! So, we have to add a new state, like:

Then, we got the class diagram:

From the state diagram, we know that the output of the EIdle state is changed and input of EWriting state is changed. Moreover, we add a EWriteMore state, this state may from EIdle and will lead you to either itself or the EWriting state.

If I map the diagram to code, that means in order to add this new state, I only need to modify the write operation in EIdle state of the existing code and let the new code deal with other things, then it's done! I will leave EWriting state alone, because it still has one pre-state and it just leads you to EIdle.

If you take a look at the implementation, you can see that most complexity that the new state brings is encapsulated with the new object. The modification of the existing code is really small.

The state pattern at least has the following advantage:

1. Force you to think about all possibilities of a state.
2. Encapsulate the most complexity that the new state brings into the new state object
3. If the new system has problems, you know where to find the bugs.

Code:

The example code could be complied using UIQ 3.0 SDK
StateMachineUIQ.zip (only 2 states)
StateMachineUIQ2.zip (added to 3 states)