State

El propósito de este patrón de diseño es facilitar que un objeto cambie su comportamiento cuando se realizan cambios en su estado interno.

La idea es evitar los problemas asociados a este estilo de código:

En el anterior código se evidencia que el método delete() se comporta de manera diferente dependiendo de si el estado actual se encuentra en alguno de cuatro posibles valores: “Proposed”, “Active”, “Resolved” o “Closed”. Un diseño como este presenta al menos los siguientes problemas:

Es necesario cambiar el método cuando se aumenten nuevos estados en una clara violación de principio Abierto/Cerrado (OCP)
El método realiza más de una tarea, una tarea por cada estado.
La lógica de negocio vinculada a un estado está dispersa en varios métodos.

Si la clase tiene varios métodos con una estructura similar, el esfuerzo necesario para agregar/eliminar estados se incrementa rápidamente haciendo que el software sea difícil de cambiar (rigidez)

La estructura general del este patrón de diseño es la siguiente:

Entonces, en lugar de emplear una sentencia condicional para determinar el comportamiento, la ejecución se delega a un objeto que representa el estado en el que actualmente se encuentra la entidad (Context). El objeto que representa el estado opera con la entidad y si es necesario cambia el objeto que representa el estado de la entidad. De esta manera, la siguiente vez que esta entidad reciba una llamada al mismo método, ésta será delegada a otro objeto (estado).