Относятся ли внутренние и / или частичные классы к принципу Государственного шаблона проектирования?

Question

В своем постоянном стремлении освоить различные шаблоны проектирования я столкнулся с шаблоном проектирования «State».

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

С моим пониманием шаблона состояния все эти изменения (создание видимых / невидимых компонентов, включение / отключение и т. Д.) Должны происходить в отдельном классе, который содержит экземпляр формы. Если различные классы State отделены от класса Form, классы State не могут получить доступ к компонентам формы. Я чувствую, что это оставляет меня с одним из двух вариантов:

1. Предоставить общедоступные компоненты формы
2. Сделать классы State внутренним классом формы

Мне кажется, что вариант (1) плохой, но мне кажется, что вариант (2) как-то нарушает дух модели состояния. Другая мысль, которая у меня возникла, заключалась в использовании option (2), но с использованием частичных реализаций классов, однако я все еще чувствую, что это нарушает дух паттерна State.

Являются ли мои чувства по поводу любого выбора несправедливыми, или есть другой вариант, о котором я даже не подумал?

Answer 1

Я бы выбрал вариант 2. «Состояние» используется только для «формы», поэтому оно семантически присуще ему, так почему бы не включить его в иерархию классов?

Answer 2

Вам не хватает третьего варианта.

Включите части, которые государство будет контролировать, как часть договора класса.

Так что, если ваша цель состоит в изменении текста метки, ваше базовое состояниекласс должен требовать, чтобы метка была отправлена ​​ему.Тогда в вашей форме может быть метод InitializeState(State myState) или BuildStates(), который устанавливает соответствующие поля.

Опция 1 неверна.Вариант 2 действительно становится ненужным, когда вы разрабатываете свое состояние так, что оно может действовать только в соответствии с тем, что ему дано, и именно так все и должно действовать в любом случае.

Answer 3

Я бы избегал частичных реализаций. Обычно они не дают никакой дополнительной выгоды и делают код более трудным для чтения. Единственное место, где я могу придумать, где частичные классы - это хорошая идея, это когда часть вашего кода генерируется автоматически (как в конструкторе WinForms).

А как насчет использования MVP или какой-либо привязки? Если вы связываете свойства Visible и Enabled ваших элементов управления с классом Model, то вы можете хранить экземпляр этой Модели вместо хранения экземпляра формы.