Design Patterns with UML: State Pattern

Clasificación del patrón: de comportamiento.
Intención: Alterar el comportamiento de un objeto según el estado interno en que se encuentre. Así, el objeto aparentará cambiar de clase.
También conocido como: Objects for States.

El comportamiento de un objeto depende de su estado, y tiene que cambiar su comportamiento en tiempo de ejecución en función de ese estado.
Se presentan muchos condicionales en el código, es posble que sea necesario aplicar este patrón.

Context: define una interface para el cliente y mantiene una instancia del estado concreto actual.
State: define una interfaz para el encapsulamiento asociado a un estado particular.
Concrete State: implementa el comportamiento de un estado del contexto.

Context delega al ConcreteState sus peticiones.
Context puede pasarse a si mismo como parámetro al ConcreteState.
Los clientes pueden configurar un Context con un ConcreteState y luego no tiene que lidiar directamente con el estado.
Tanto Context como ConcreteState pueden decidir qué estado sucede a otro y bajo qué circunstancias.

Se localizan fácilmente las responsabilidades de los estados específicos. Esto facilita la ampliación de estados.
Hace los cambios de estado explícitos puesto que en otros tipos de implementación los estados se cambian modificando valores en variables
Evita la utlización de estructuras condicionales.
Se incrementa el número de subclases.
Impone una estructura sobre el código y hace más clara su intención.
Hace explícitas las transiciones entre cuándo se tiene que ejecutar un comportamiento u otro.
Los objetos state pueden ser compartidos por varios contextos.
Permite a un objeto cambiar de clase en tiempo de ejecución

Table-driven state machines: define transiciones de estado en una tabla. Esto convierte el código condicional en una tabla de consulta. Así, se puede cambiar los criterios de transición mediante la modificación de datos en lugar de cambiar el código del programa.
Creación y destrucción de objetos de estados. Se presentan dos posibilidades:

Crear el objeto cuando es necesario, utilizarlo y destruirlo. Es útil cuando no se sabe qué estado tomará el objeto en tiempo de ejecución.
Crear todos los estados de antemano, utilizar alguno cuando sea necesario y nunca destruirlos. Es apropiado cuando se requieren rápidos cambios de estado. La desventaja es que el contexto debe mantener una referencia por cada estado.

Se puede reemplazar el patrón State por herencia, cambiando la clase del objeto en tiempo de ejecución, pero esto no es posible en la mayoría de los lenguajes de programación orientados a objetos, salvo raras excepciones como Self.