State |
|---|
 | | Concepto: | Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo. |
|
State. El patrón de diseño Iterator se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo, dando así la impresión de que el objeto cambia de clase.
Como usarlo
- Cuando el comportamiento de un objeto depende de su estado y debe poder cambiar dinámicamente (en tiempo de ejecución) dicho comportamiento, a medida que cambie dicho estado.
- Cuando las operaciones tienen definiciones largas y con múltiples condiciones, dependientes del estado del objeto, siendo lo más adecuado separar en objetos independientes cada condición atómica, para poder así combinarlas y modificarlas independientemente, ya sea en estados ya existentes, ya en otros nuevos que se formen combinándolos.
Ventajas
- Dado que el comportamiento específico de cada estado está autocontenido en cada estado concreto, existe una gran flexibilidad para añadir nuevos estados y transiciones, mediante la definición de nuevas subclases.
- A pesar de que la distribución del comportamiento ante diferentes situaciones entre diferentes objetos incrementa el nº de clases y reduce la compacidad, es la mejor solución cuando hay muchos estados, pues evita las definiciones multicondicionales y grandes, tan indeseables como los procedimientos gigantes lo son en el estilo imperativo.
- Se hacen más explícitas las transiciones entre estados que sí todo estuviera concentrado en una sola clase (esto hace más inteligible el diseño), impidiendo además los estados internos inconsistentes (desde el punto de vista del contexto, los cambios de estado son atómicos.
- Si los objetos que representan los estados no tienen variables de instancia (esto es, el estado está totalmente definido en su propio tipo) entonces diferentes contextos pueden compartir estados, como PesoMosca sin estado intrínseco, sólo comportamiento.
Relacionado con
- PesoMosca explica como los objetos Estado pueden ser compartidos.
- Los objetos Estado a menudo son Solitarios.
Otros aspectos de interés
- La misión de Contexto es definir la interfaz que interesa a los clientes, mientras mantiene una referencia al Estado actual. Si dicho Estado necesita tener acceso al Contexto al que está asociado, éste puede pasarse a si mismo como parámetro de la petición.
- Si los estados que van a hacer falta no se conocen a priori y el Contexto cambia de Estado poco frecuentemente, es mejor ir creando/destruyendo estados sobre la marcha. Pero si el Contexto cambia constantemente de Estado es preferible crear todos los estados al comienzo y no destruirlos nunca (puede volver a hacer falta).
- Las transiciones entre estados pueden estar prefijadas a priori en el Contexto o pueden dejarse a la responsabilidad de cada estado, que tendrá entonces que saber quien le sucede (aparte de este inconveniente, esta solución es más flexible y, por ello, preferible). Otra alternativa es una transición entre estados definida tabularmente. Esto permite cambiar el criterio de transición cambiando solamente los datos de entrada, pero es menos eficiente, hace menos explícitas las transiciones entre estados y dificulta el añadir acciones a dichas transiciones.
- Algunos lenguajes (Self) permiten a un objeto cambiar de clase en tiempo de ejecución, en lo que constituye una especie de herencia dinámica; esto es, soportan directamente este patrón.
Fuentes
