Извинения, если это ответ в другом месте; не смог найти достаточно информации, чтобы убедить себя в том, что это лучший способ сделать это. Я также понимаю, что это длинное объяснение без кода, но дайте мне знать, если мне нужно набросать некоторый пример кода, чтобы помочь продемонстрировать, что я делаю.

В принципе:

implementing a communication protocol in Java using System.in/out current approach is implementing a state pattern where a Scanner is instantiated on System.in in the context class concrete states invoke a context method to read from the Scanner, and subsequently perform actions/transition states appropriately based on the value returned by the Scanner

Мое первоначальное намерение использовать шаблон состояний состояло в том, чтобы упростить код при синтаксическом анализе таких последовательностей из System.in (не спрашивайте о синтаксисе, это то, с чем я должен работать):

COMMAND NAME=X HEADER line of header information CONTENTS lines of command contents ENDCONTENTS ENDCOMMAND

Я обычно определяю конкретное состояние для каждого типа команды, которую ожидаю получить. Используя приведенную выше последовательность в качестве примера, я бы получил набор состояний, который выглядел примерно так: {WAITING_FOR_COMMAND, COMMAND_RECEIVED, PARSING_HEADER, PARSING_CONTENTS, PARSING_DONE, COMMAND_PROCESSED}. Сначала я буду в WAITING_FOR_COMMAND, а затем, когда "COMMAND NAME = X" получено, что я перешел к COMMAND_RECEIVED, тогда, когда "HEADER" пришел в I переход к PARSING_HEADER и т. д. Этот дизайн облегчает прохождение всех крайних случаев в протоколе, а также облегчает обновление / сопровождение кода, когда протокол настраивается. Очевидно, намного лучше, чем массивные операторы switch и повторяющиеся проверки границ.

Проблема, с которой я сталкиваюсь, заключается в том, что я обнаруживаю все больше и больше переменных состояния в классе контекста, когда я конкретизирую свое конкретное поведение состояния, и знаю, что это, вероятно, плохо, поскольку я создаю очень открытые интерфейсы и очень высокие связи между контекст и конкретные государственные классы. Последовательности команд в этом протоколе могут быть произвольно длинными, и мне нужно сохранять информацию, передаваемую каждым элементом в последовательности команд, до тех пор, пока последовательность команд не будет завершена.

Используя приведенную выше последовательность команд в качестве примера, после «COMMAND ID = X» я хочу сохранить значение X для будущего использования после того, как получу «ENDCOMMAND». и полностью обработать команду. После «HEADER» я хочу сохранить информацию заголовка для будущего использования после того, как получу «ENDCOMMAND». когда я на самом деле обрабатываю команду. Так далее и тому подобное. Простое добавление переменных контекста commandId и заголовка в класс контекста пока работает, но мне не кажется чистым или хорошо инкапсулированным.

У кого-нибудь есть предложения высокого уровня о том, как они подходят к этой проблеме? Для этого лучше использовать шаблон государственного дизайна?

Просто отметьте некоторые идеи, с которыми я играю:

defining state contexts for each type of command sequence, and invoking the appropriate context upon receiving the relevant command from System.in; this seems almost as messy as having giant switch blocks, and seems to overly convolute the design designing a full-blown FSM architecture that supports composite FSMs, where each command sequence occupies its own FSM within an overarching FSM; this seems like overkill to me creating a ProtocolCommand object with various subclasses for each command sequence type; I could pass these into each state when transitioning, and gradually build them up as I go...but this clutters the state interface and forces all states to ingest a parameter that they won't necessarily use

Спасибо! Извините, это было настолько многословно, дайте мне знать, если я смогу что-то уточнить.