Desculpas se isso for respondido em outro lugar; Não encontrei informações suficientes para me convencer da melhor maneira de fazer isso. Eu também percebo que esta é uma longa explicação sem código, mas me avise se eu precisar criar um exemplo de código para ajudar a demonstrar o que estou fazendo.

Basicamente:

implementando um protocolo de comunicação em Java usando System.in/outA abordagem atual está implementando um padrão de estado em que um Scanner é instanciado em System.in na classe de contextoestados concretos invocam um método de contexto para ler do Scanner e, subsequentemente, executam ações / estados de transição apropriadamente com base no valor retornado pelo Scanner

Minha intenção original de usar um padrão de estado era simplificar o código ao analisar sequências como esta em System.in (não pergunte sobre a sintaxe, é algo com que tenho que trabalhar):

NOME DE COMANDO = XCABEÇALHOlinha de informação de cabeçalhoCONTEÚDOlinhas de conteúdo de comandoENDONDTENTSENDCOMMAND

Eu geralmente defino um estado concreto para cada tipo de comando que espero receber. Usando a seqüência acima como exemplo, eu teria um conjunto de estados que se parecesse com algo como {WAITING_FOR_COMMAND, COMMAND_RECEIVED, PARSING_HEADER, PARSING_CONTENTS, PARSING_DONE, COMMAND_PROCESSED}. Eu inicialmente estaria em WAITING_FOR_COMMAND, então quando "COMMAND NAME = X" é recebido, eu passaria para COMMAND_RECEIVED, então quando "HEADER" chegasse eu passaria para PARSING_HEADER, etc. Esse design faz atravessar todos os casos de borda em o protocolo mais fácil, e também torna o código fácil de atualizar / manter quando o protocolo é ajustado. Obviamente, muito melhor do que declarações massivas de chaves e verificações de limite repetitivas.

O problema que estou tendo é que eu me encontro declarando mais e mais variáveis ​​de estado na classe de contexto enquanto desenvolvo meus comportamentos de estado concreto, e sei que isso é provavelmente ruim, já que estou criando interfaces muito expostas e ligações muito altas entre o classes de estado de contexto e concreto. As seqüências de comandos neste protocolo podem ser arbitrariamente longas, e eu preciso salvar as informações transmitidas por cada item na sequência de comandos até que a sequência de comandos esteja completa.

Usando a seqüência de comandos acima como um exemplo, depois de "COMMAND ID = X", quero salvar o valor X para uso futuro depois de receber "ENDCOMMAND" e processar totalmente o comando. Depois de "HEADER", quero salvar as informações de cabeçalho para uso futuro depois de receber "ENDCOMMAND" para quando realmente processar o comando. Então, e assim por diante. Simplesmente adicionar as variáveis ​​de estado commandId e header à classe de contexto funciona por enquanto, mas não parece nada limpo ou bem encapsulado para mim.

Alguém tem alguma sugestão de alto nível sobre como abordar esse problema? Existe um melhor uso de um padrão de design de estado para isso?

Apenas para anotar algumas ideias com as quais tenho jogado:

definindo contextos de estado para cada tipo de seqüência de comandos e chamando o contexto apropriado ao receber o comando relevante de System.in; isso parece quase tão confuso quanto ter blocos de interruptores gigantes, e parece envolver demais o designprojetar uma arquitetura FSM completa que suporte FSMs compostos, em que cada seqüência de comandos ocupa seu próprio FSM dentro de um FSM abrangente; isso parece um exagero para mimcriando um objeto ProtocolCommand com várias subclasses para cada tipo de sequência de comando; Eu poderia passá-los em cada estado durante a transição, e gradualmente construí-los como eu vou ... mas isso desordena a interface de estado e força todos os estados a ingerirem um parâmetro que eles não usarão necessariamente

Muito obrigado! Desculpe isso foi tão detalhado, deixe-me saber se eu posso esclarecer alguma coisa.