¿El patrón de estado representa con precisión el enfoque?

Question

Lo que deduzco de implementación típica de State pattern s es la siguiente:

Problema: representar un objeto O, cuyo comportamiento se altera en función de su estado actual.
Solución:
1. Sea S , otro objeto dentro de este objeto O, representan estado
2. El objeto S invocará la operación apropiada de O
3. El objeto S decidirá el siguiente estado para el objeto O

Mi preocupación es principalmente w ith #3. La tabla de transición del estado está esencialmente distribuida en todos los estados. He visto que estas soluciones se vuelven engorrosas de administrar muy rápidamente. En lugar de ser un indicador, estos estados contienen demasiada información sobre la máquina de estado.
Aunque me molesta #2, creo que es bastante razonable (Moore machine). El único problema que he visto surge durante la corrección/depuración de errores: el código de navegación/comprensión se vuelve difícil hasta que uno confía todas las asignaciones de estado a la memoria.

¿La siguiente implementación sería más precisa?
Representa estados como enumeraciones, y el objeto decide la acción según el valor que tiene la enumeración. state transitions están en una tabla (δ, una función de transición de estado) que es un mapa del estado actual al estado siguiente. Este state transition table también contiene la acción que se realizará (Mealy machine)

Answer 1

No sé por qué supones que el patrón de estado solo puede representar máquinas Moore.

void SleepingState::alarm() 
{ 
    kick_alarm_clock(); 
    set_state(new GrumpyState()); 
} 

Elegimos nuestra salida (kick_alarm_clock) basado tanto en el estado (SleepingState) y el evento (alarma), lo que hace que sea una máquina Mealy.

Su alternativa es de hecho válida y popular (y hay otras). Dado que varios enfoques son suficientes para implementar la lógica de la máquina, usted toma la decisión basándose en otras consideraciones de 'diseño' o gusto personal. Las razones de diseño para preferir el patrón estatal pueden ser si cree que a menudo agregará nuevos estados, o si algunos estados parecen lo suficientemente similares como para justificar una relación de herencia. Tiendo a elegir en estética: utilizo el patrón de estado solo si la máquina es bastante densa, es decir, hay acciones no triviales & transiciones para la mayoría de los pares de {state, event}. Si la máquina es bastante escasa, me avergüenzan todos los métodos vacíos.