design patterns - strategy - Patrón de máquina de estado finito: ¿El único patrón verdadero?
patron strategy java (2)
El código de espagueti nunca es la respuesta correcta. Los patrones son buenos para limpiar el código de espagueti, pero solo con un diseño bien pensado puede lograr lo mismo.
Con respecto a la pregunta de la máquina de estados: personalmente los encuentro muy útiles. Para una aplicación pública que creé, volví a utilizar un gráfico de estado (que creo que es lo mismo que la máquina de estado) y noté los beneficios que mencionó. Es una abstracción realmente útil, porque le permite separar la preocupación de manejar eventos en un componente separado. Con esto, los errores desaparecen porque la gráfica de estado sabe de manera implícita lo que un usuario puede hacer dónde, y dado que los eventos solo se manejan en el lugar correcto, realmente no se puede realizar una acción no válida. Además, el uso de la gráfica de estado me permitió simplificar el código porque podía extraer todo el código de manejo de eventos de donde estaba y colocarlo en un lugar donde se suponía que estaba, en otras palabras, otros componentes no estaban No se complica al tener también controladores de eventos en ellos.
Una imagen vale más que mil obras. Aquí está el diseño que se me ocurrió:
Con esto, cualquiera que lo vea, sabe exactamente cómo se comporta la aplicación en un nivel alto. Es difícil romper esto, porque como dije, no puedes llegar a un estado inválido porque los controladores de eventos controlan exactamente dónde puedes ir; si puede llegar a un estado no válido, es un error de implementación que se soluciona fácilmente. Además, los beneficios de limpieza de código son enormes. Por ejemplo, con el gráfico de estado, cada vez que ingreso un estado en pausa, puedo hacer cosas como detener el reloj, poner una máscara en el tablero, etc. Son unas pocas líneas de código en un lugar , porque cuando entro en un subestado de pausado el gráfico pasa por el estado padre primero. sin el gráfico de estado, tendría que hacer ese código en todos los lugares donde se manejó un evento.
No sé si debe ser una función de nivel de idioma, pero tener un marco bien implementado es bueno.
¿Se podría mejorar todo el código escrito aplicando el patrón de máquina de estado?
Estaba trabajando en un proyecto que era una masa de código de espagueti roto horrible, horrible, con errores. Copié el código State Machine de ejemplo de Martin Fowler de este blog y transformé todo el montón de basura en una serie de declaraciones. Literalmente solo una lista de Estados, Eventos, Transiciones y Comandos.
No puedo creer la transformación. El código ahora está limpio, y funciona. Por supuesto, antes era consciente de State Machines e incluso los he implementado, pero en el ejemplo de Martin Fowler, la separación del modelo / configuración es sorprendente.
Esto me hace pensar que casi todo lo que he hecho podría beneficiarse de alguna manera con este enfoque. Quiero esta funcionalidad en todos los idiomas que uso. Tal vez esto debería ser incluso una característica de nivel de idioma.
¿Alguien piensa que esto está mal? ¿O alguien tiene una experiencia similar con un patrón diferente?
Las máquinas de estados finitos (FSM) y, más específicamente, los idiomas específicos del dominio (DSL) hacen que sea más fácil relacionar un problema con un dominio de solución específico, describiendo la solución en un idioma especializado.
Las limitaciones del patrón de State Machine es que en sí mismo constituye un lenguaje de programación, pero para el cual tiene que escribir sus propias herramientas de ejecución, prueba y depuración; y uno que cualquier mantenedor tiene que aprender. Ha movido la complejidad de su código a una configuración FSM compleja. Ocasionalmente, esto es útil, pero ciertamente no universalmente.
Y dado que cualquier computadora de von Neumann es en sí misma un FSM, ciertamente cualquier programa puede ser refundido de esta manera.