Использовать или не использовать Шаблон состояния?
Я разрабатываю игру пинбола для проекта Uni, в котором там, как предполагается, 2 режима: рабочий режим и режим разработчика, посредством чего можно разработать/перепроектировать расположение машины.
Моя начальная буква думала, был шаблон состояния - однако, я обеспокоен, что единый интерфейс между состояниями может сократить их в реализацию методов, которые не соответствуют тому состоянию.
Например, В режиме разработчика было бы совершенно уместно установить положение бампера или безотносительно; но в рабочем режиме это было бы реализовано как выполнение ничего или выдача исключения - который просто кажется противным, особенно если существует много таких методов.
Существует ли лучший дизайн для этого?
2 ответа
Ваша интуиция правильная. Узор государства полезен, когда программа может иметь много разных состояний, каждый из которых поддерживает многие из тех же операций. Например, программа для рисования может иметь много разных инструментов, но каждый поддерживает аналогичные операции, такие как положить ручку вниз или вверх, и рисуя линию между 2 точками.
В вашем случае есть только 2 государства, и они не разделяют много поведения. Главное, что они делятся, - это общие операции GUI, которые, вероятно, уже в стандартной библиотеке. Вам нужно обеспечить, чтобы код для таких вещей, как отображение бамперов, не дублируется, но вы можете сделать это без состояния.
Пару лет назад у меня было похожее назначение в университете.
Я бы сказал, что используя шаблон состояния - это изготавливание для этого, а также не совсем подходящую, как упоминалось ранее. Что мы сделали с этим заданием:
- использовать что-то выше различных режимов, что позволяет переключаться между ними.
- Каждый режим не знает о другом режиме, они не совершают звонков друг на друга.
- Они делятся знаниями о модели, хотя (которая в вашем деле будет платой Pinball, с позициями бамперов, шаров и т. Д.), поэтому, когда вы переключаетесь между ними, они являются последовательными.
- С точки зрения графического интерфейса каждый режим в основном дан пространство для этого. Как вы говорите, каждый режим имеет разные возможные действия, поэтому вынуждая их обмениваться теми же действиями, что и часть штата «вонючий».
В основном, как упомянуто в другом месте, два режима не разделяют достаточно общность, чтобы действительно оправдать шаблон состояния здесь.
Существует одна вероятность применения состояния, которая имеет смысл. Поскольку это университетское задание, вероятно, будет кредитоспособным к мысли и оправданию за ним. Это связано с «уровнем выше», который я упоминал ранее. По моему опыту это было частью GUI, которая была независима от режима. Это позволило тому, как закрывать приложение, открывая предыдущие конфигурации Pinball, и переключение между режимами. То, что он также может сделать, это показать контекстно-зависимые пункты меню. Состояние меню может быть получено из текущего режима. Таким образом, режим Builder может включать в себя сохранение и другие конкретные действия построителя, а режим работы может предложить варианты воспроизведения / паузы. Если вы потратили время, расследование штата-шаблона, и пожелайте для этого окупаться, это будет возможный вариант.
P.S. Мюррей казался энтузиазмом о нашем использовании конструктивных узоров в то время; -)