Cell Phone - An implementation of behavioral pattern to describe the states

An article on the State pattern describing cell phone states behavior.

For more details and source code for my article please go to this Location on Codeproject. 

Introduction

A Finite State Machine (FSM) is the significant model for designing dynamic behavior, i.e., to receive events from a finite collection and keep track of the current state and the previous state, and provide a mechanism for changing states based on an event from a set of predetermined events. The implementation is the state-transition system based on the trendy cell phone activities developed in .NET.

Finite State Machine

No FSM is an isolated process. Every aspect of an FSM depends on its context, requirements, limitation of programming language and other factors. The most popular non-object oriented implementations of FSM are cascading if statements, nested switch statements, state transition tables and code using goto statements. Their popularity is due to fast execution, but at the cost of weaker reliability and maintainability. On the other hand, the pure Object-Oriented FSM designs require “Complete Reification”, that is, making every element of the state machine an object. Finite State Machine implementation comes from “the Gang of Four” (GoF) with their design pattern “The State Pattern”. This is an object-oriented approach with a tightly coupled structure of classes or class hierarchy for each state and event.
A Finite State Machine has at least two common characteristics:

1. First, a distinct, finite number of states exist.
2. Second, methods exist that facilitate movement between the states, i.e., transition.

The State Pattern

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. The solution is provided in the following way; each state is encapsulated in a separate class that implements the common State interface (IState) and defining the behavior to handle all external events. The Context class is responsible for maintaining the knowledge of the current state and other data. External entities communicate with the system via the Context class that forwards requests to the current state object. There are the following consequences while using the State Pattern.

1. State specific behavior is localized and partitioned between different states.
2. State transition is performed exactly in the code.
3. If an object has many states, many concrete classes need to be created, which may result in an excessively large class hierarchy.
4. The Context class delegates all external events to corresponding methods in the interface of the State class; it is responsible for providing the correct mapping. This results in a tight coupling between the Context class and concrete events.
5. The Context class keeps one instance of each state in a hash table so that state changes does not result in creation or deletion of objects.
6. The Context class keeps many state objects, but only one is active (i.e., responds to events) at a given time.

  For more details and source code for my article please go to this Location on Codeproject.