Использовать или не использовать State Pattern?

Question

Я разрабатываю игру в пинбол для проекта Uni, в которой должно быть 2 режима: режим бега и режим строителя, в соответствии с которым можно проектировать / перепроектировать макет машины.

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

Например.В режиме конструктора было бы вполне уместно установить положение бампера или чего-либо еще;но в режиме выполнения это будет реализовано как ничего не делать или выдавать исключение - что просто кажется неприятным, особенно если таких методов много.

Есть ли лучший дизайн для этого?

Answer 1

Ваша интуиция верна. Шаблон состояний полезен, когда программа может иметь много разных состояний, каждое из которых поддерживает множество одинаковых операций. Например, программа для рисования может иметь много разных инструментов, но каждая из них поддерживает похожие операции, такие как опускание пера или подъема и рисование линии между 2 точками.

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

Answer 2

Пару лет назад у меня было подобное назначение в университете.

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

• Используйте что-то над различными режимами, что позволяет переключаться между ними.
• Каждый режим не знает другого режима, они не звонят друг другу.
• Тем не менее, они делятся знаниями о модели (которая в вашем случае будет доской для пинбола, с позициями бамперов, мячей и т. Д.), Поэтому при переключении между ними они согласуются.
• С точки зрения графического интерфейса каждому режиму в основном предоставляется пространство для выполнения своих задач. Как вы говорите, у каждого режима есть разные возможные действия, поэтому принуждать их использовать одни и те же действия как часть шаблона состояния "вонючий".

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

Существует одна возможность применения схемы состояний, которая имела бы смысл. Поскольку это университетское задание, вероятно, стоит отдать должное за мысль и обоснование. Это связано с «уровнем выше», о котором я упоминал ранее. По моему опыту это было частью графического интерфейса, который был независим от режима. Это позволяло закрывать приложение, открывать предыдущие настройки пинбола и переключаться между режимами. Он также может показывать контекстно-зависимые пункты меню. Состояние меню может быть получено из текущего режима. Таким образом, режим компоновщика может включать в себя сохранение и другие специфичные для компоновщика действия, а режим выполнения может предлагать варианты воспроизведения / паузы. Если вы потратили время на изучение модели состояния и хотите, чтобы это окупилось, это было бы возможным вариантом.

P.S. Мюррей, казалось, с энтузиазмом относился к тому, как мы использовали шаблоны проектирования в то время; -)