design patterns - source - ¿Cuál es la diferencia entre una máquina de estado y la implementación del patrón de estado?
patron de diseño state ejemplo c++ (5)
Me pregunto si una máquina de estado es solo el patrón de estado en el trabajo o si realmente hay una diferencia entre esos dos.
Encontré este artículo con el título en negrita "el patrón de diseño de estado frente a la máquina de estado" pero al final del día él solo dice que el patrón de estado hace que las máquinas de estado sean obsoletas, pero luego no describe qué es exactamente una máquina de estado en comparación con Implementación del patrón estatal .
una máquina de estado es solo el patrón de estado en el trabajo o si en realidad hay una diferencia entre esos dos
TL; DR: Imagina que necesitas reemplazar un estado con otro que se comporta de manera diferente. Entonces imagina que necesitas agregar un nuevo estado.
Respuesta completa. Existe una gran diferencia.
El patrón de estado abstrae los estados y los desacopla uno de otro. Así, por ejemplo, puede reemplazar fácilmente un estado particular por otro. Sin embargo, no estará contento al reescribir todos los estados cuando sea el momento de agregar uno nuevo y / o una nueva transición.
La máquina de estados abstrae el propio diagrama de estado y lo desacopla de las cargas útiles de transición. Para cambiar un estado particular, tienes que arreglar todo el diagrama. Pero para agregar un estado o transición, solo necesita arreglar el diagrama.
En caso de que alguien siga interesado, aquí está mi punto de vista:
En la máquina de estados, el objeto puede estar en diferentes estados, pero no nos importa realmente cómo se comportan en esos estados. De hecho, solo nos importa qué acción se aplica cuando el objeto se pasa al siguiente estado. Si implementa una máquina de estado en Java, un estado será solo una enumeración o una cadena y habrá una clase de transición con el método doAction ().
Por otro lado, en el patrón de estado, realmente no te importa la transición, sino cómo se comporta el objeto en esos estados. La transición es solo un detalle de la implementación para que los comportamientos de su estado se desacoplen entre sí. Cada estado será una clase separada, teniendo su propio método doAction ().
Decir patrón de estado hace que la máquina de estado sea obsoleta es incorrecto. El patrón de estado será útil si el comportamiento de cada estado es importante, por ejemplo, en la programación de juegos, donde un objeto puede tener estados como "inactivo", "ataque", "correr" y en cada estado en el que desee implementar el comportamiento del objeto .
Pero para casos de uso como ordenar productos en línea, donde no le importa cómo se comporta el objeto de pedido. Solo importa si el pedido está en el estado "added_to_cart", cuando se publica un evento "payment_finished", luego cámbielo al estado "procesando". En este caso, el estado es una propiedad de enumeración simple de la clase Orden, por lo que usar la máquina de estados es mucho mejor.
La forma en que describo esta diferencia a mis colegas es que los patrones de estado son una implementación más descentralizada de muchos estados encapsulados independientes mientras que las máquinas de estados son más monolíticas. La naturaleza monolítica de las máquinas de estado significa que un solo estado será más difícil de reutilizar en una máquina diferente y que es más difícil dividir una máquina de estados en múltiples unidades de compilación. Por otro lado, este diseño monolítico permite una mejor optimización de las máquinas de estado y permite que muchas implementaciones representen toda la información de transición en un solo lugar en una tabla. Esto es especialmente adecuado para situaciones en las que la persona responsable de la arquitectura o función de la máquina estatal no está bien versada en el lenguaje de programación en el que se implementa. Recuerde que muchas carreras de ingeniería y matemáticas han aprendido acerca de las máquinas estatales pero tienen poca o ninguna educación en el campo. Campo de programación. Es mucho más fácil presentar a este tipo de personas una tabla de transiciones, acciones y guardias que las páginas y las páginas de patrones de estado.
Aunque el artículo en realidad fue una buena lectura, no estoy de acuerdo con el autor en varios puntos:
- "Ya no hay razón para usar máquinas de estado cuando se usa un lenguaje de programación orientado a objetos" esto no es categóricamente cierto si tiene algún requisito sobre la velocidad de ejecución.
- La idea de que la implementación de los autores sea particularmente breve o simple o que requiera menos mantenimiento que la cámara digital de boost statecharts depende de su caso de uso y gusto personal, pero no se puede decir de manera catastrófica. http://www.boost.org/doc/libs/1_55_0/libs/statechart/doc/tutorial.html#IntermediateTopicsADigitalCamera
Tenga en cuenta que el cambio de estado requiere una asignación! Esto va a matar la velocidad. Esto podría remediarse colocando todos los estados en un búfer uno al lado del otro para guardar una falta de caché o dos. Sin embargo, esto requeriría cambios importantes en el ejemplo de los autores.
También tenga en cuenta que los eventos que no se manejan no se pueden alinear y optimizar como en las máquinas de estado estático porque con el patrón de estado están detrás de una capa de direccionamiento dinámico. Esto también es un potencial asesino de eficiencia en función de sus necesidades.
Desde el punto de vista de mantenimiento, se debe tener en cuenta que el registro de eventos no controlados no se puede realizar desde un superestado central con el patrón de estado. ¡Además, la adición de un nuevo tipo de evento / función de controlador requiere agregar una función a todos los estados! No considero que el mantenimiento sea amigable.
También prefiero ver todas las transiciones en una tabla en lugar de mirar a través del funcionamiento interno de cada estado. El autor tiene razón en que agregar un estado es más fácil, pero solo de manera mínima, con las estadísticas de impulso, por ejemplo, solo tengo que agregar el estado a la lista de los estados hijos de los padres, esa es la única diferencia real.
Utilizo el patrón de estado en los casos en que la velocidad no es un problema y donde la jerarquía de la máquina de estado probablemente permanecerá plana. El autor está en lo cierto al afirmar que la implementación inicial suele ser más fácil con el patrón de estado en comparación con una máquina de estados y que, en general, más programadores deberían usar más máquinas de estados.
Un argumento para el patrón de estado es que permite la implementación de máquinas de estado "Abierto Cerrado" donde una máquina de estado puede definirse en una biblioteca y luego ser expandida por el usuario, esto no es posible hasta donde sé con la máquina de estado principal marcos
Noto una diferencia con el patrón de estado. Es más útil cuando se usa para la interfaz de usuario. Digamos que quería bloquear el estado. en el contexto del patrón de estado, podría crear un valor booleano e impedir que los estados cambien aún más.
Aquí hay un ejemplo de Kotlin:
inner class StateContext : State {
private var stateContext: State? = null
private var lockState: Boolean = false
fun isLockState(): Boolean {
return lockState
}
fun setLockState(lockState: Boolean): StateContext {
this.lockState = lockState//no further actions allowed. useful if you need to permenatley lock out the user from changing state.
return this
}
fun getState(): State? {
return this.stateContext
}
fun setState(state: State): StateContext {
if (!lockState) this.stateContext = state
return this
}
override fun doAction() {
this.stateContext?.doAction()
}
}
con la máquina de estados no estoy seguro de cómo se haría fácilmente.
Realmente me gusta la máquina de estado cuando estoy preocupado solo por el estado (por ejemplo, se guarda la enumeración del estado actual), no por el detalle de la implementación real (por ejemplo, cambiar el color de los botones de la IU). Lo único bueno de la máquina de estado es que puede tener un lugar central para registrar cambios de estado. Vi esta biblioteca para kotlin por yesca que parece interesante. pero personalmente creo que podría cambiarlos todos para hacer lo que quiera, solo que de una manera más limpia a otra.
Una máquina de estado puede ser diseñada e implementada de varias maneras. Una forma es usar el patrón de estado descrito en el libro por la pandilla de los cuatro. Pero hay otros patrones para implementar una máquina de estados.
Por ejemplo, puede querer echar un vistazo a la investigación de Miro Samek leyendo el libro Practical UML statecharts en C / C ++, 2ª ed. (Programación dirigida por eventos para sistemas embebidos)
También puede encontrar interesante esta pregunta .