Disculpas si esto se responde en otro lugar; No pude encontrar suficiente información para convencerme de la mejor manera de hacer esto. También me doy cuenta de que esta es una explicación larga sin código, pero hágame saber si debo preparar un código de muestra para ayudar a demostrar lo que estoy haciendo.

Básicamente:

implementando un protocolo de comunicación en Java usando System.in/outel enfoque actual es implementar un patrón de estado en el que se crea una instancia del Escáner en System.in en la clase de contextolos estados concretos invocan un método de contexto para leer desde el escáner y, posteriormente, realizan acciones / estados de transición de manera apropiada en función del valor devuelto por el escáner

Mi intención original de usar un patrón de estado era simplificar el código al analizar secuencias como esta de System.in (no pregunte acerca de la sintaxis, es algo con lo que tengo que trabajar):

NOMBRE DE COMANDO = XENCABEZAMIENTOlínea de información del encabezadoCONTENIDOcontenidos de líneas de comandoENDCONTENTSENDCOMMAND

Generalmente defino un estado concreto para cada tipo de comando que espero recibir. Usando la secuencia anterior como ejemplo, tendría un conjunto de estados que se parecía a {WAITING_FOR_COMMAND, COMMAND_RECEIVED, PARSING_HEADER, PARSING_CONTENTS, PARSING_DONE, COMMAND_PROCESSED}. Inicialmente estaría en WAITING_FOR_COMMAND, luego, cuando se recibe "COMMAND NAME = X", pasaría a COMMAND_RECEIVED, luego, cuando entrara "HEADER", haría la transición a PARSING_HEADER, etc. El protocolo es más fácil y también hace que el código sea fácil de actualizar / mantener para cuando el protocolo se modifique. Obviamente, mucho mejor que las declaraciones de cambio masivo y las comprobaciones de límites repetitivas.

El problema que tengo es que me encuentro declarando cada vez más variables de estado en la clase de contexto a medida que realizo mis comportamientos de estado concretos, y sé que esto es probablemente malo ya que estoy creando interfaces muy expuestas y vínculos muy altos entre los Contexto y clases concretas del estado. Las secuencias de comandos en este protocolo pueden ser arbitrariamente largas, y necesito guardar la información impartida por cada elemento en la secuencia de comandos hasta que se complete la secuencia de comandos.

Utilizando la secuencia de comandos anterior como ejemplo, después de "COMMAND ID = X", quiero guardar el valor X para uso futuro después de recibir "ENDCOMMAND" y procesar completamente el comando. Después de "HEADER", quiero guardar la información del encabezado para un uso futuro después de recibir "ENDCOMMAND" para cuando realmente procese el comando. Y así sucesivamente. El simple hecho de agregar commandId y las variables de estado del encabezado a la clase de contexto funciona por ahora, pero no me parece en absoluto limpio o bien encapsulado.

¿Alguien tiene alguna sugerencia de alto nivel sobre cómo abordar este problema? ¿Hay un mejor uso de un patrón de diseño de estado para esto?

Solo para anotar algunas ideas con las que he estado jugando:

definiendo contextos de estado para cada tipo de secuencia de comando, e invocando el contexto apropiado al recibir el comando relevante de System.in; esto parece casi tan desordenado como tener bloques de interruptores gigantes, y parece que convulsiona demasiado el diseñodiseñar una arquitectura FSM completa que admita FSM compuestas, donde cada secuencia de comandos ocupa su propia FSM dentro de una FSM general; esto me parece una exageracióncreando un objeto ProtocolCommand con varias subclases para cada tipo de secuencia de comando; Podría pasar esto a cada estado durante la transición, y construirlos gradualmente a medida que voy ... pero esto desordena la interfaz del estado y obliga a todos los estados a ingerir un parámetro que no necesariamente usarán

¡Muchas gracias! Perdón, esto fue tan detallado, hazme saber si puedo aclarar algo.