Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

   // 2. Настройка переменных/состояния игры, соответствующих

   // данному режиму работы

   //

   // SetUpGameStateForCongratulateUser();

   break;

  case GameState.ScoldUser:

   //Если переход в данное состояние осуществляется из состояния,

   //для которого это запрещено, возбудить исключение

   if (m_CurrentGameState != GameState.AskQuestion) {

    throw new System.Exception("Запрещённый переход!");

   }

   //ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:

   // 1. Скрытие (Hide), отображение (Show) и перемещение (Move)

   // элементов управления пользовательского интерфейса

   // 2. Настройка переменных/состояния игры, соответствующих

   // данному режиму работы

   //

   // SetUpGameStateForScoldUser();

   break;

  default:

   throw new System.Exception("Неизвестное состояние!");

  }

  //Сохранить запрошенное новое состояние в качестве текущего

  m_CurrentGameState = newGameUIState;

 }

} //Конец класса

Явно и неявно определенные конечные автоматы

Планируете ли вы это или не планируете, но ваш код будет так или иначе управляться состояниями. Например, если какой-либо элемент управления необходимо сделать недоступным для пользователя, то разработчики часто добиваются этого, устанавливая для свойств Enabled и Visible этих элементов управления значение false (например, TextBox1.Visible = false;). Для написания кода такого типа существует два возможных подхода, которые рассматриваются ниже

Подход 1: зависящее от специфики конкретной ситуации, децентрализованное, неявное управление состояниями (неудачный подход)

Специализированный стиль проектирования, ориентированный на максимально возможный учет специфики конкретной задачи, часто встречается в тех случаях, когда приложение в процессе разработки постепенно усложняется. Различные аспекты состояния приложения изменяются в разных местах приложения. Данные о состоянии хранятся в таких свойствах элементов управления, как Visible, Enabled, Size или Position. Переменные, используемые для хранения ключевой информации о состоянии, изменяются непосредственно в тех строках кода, где это оказывается необходимым, а загрузка данных и освобождение памяти от них распределяются по всему приложению в зависимости от конкретной ситуации. Развитие событий напоминает "перетягивание каната" между различными частями приложения, поскольку каждая из функций делает все необходимое для выполнения возложенных на нее задач, не обращая никакого внимания на остальную часть приложения. Простейшим примером подобного поведения может служить код, реагирующий на такие события пользовательского интерфейса, как щелчок на кнопке, которой соответствует встроенный код, изменяющий состояние приложения. В листинге 5.2 приведен типичный код, встречающийся в классах формы приложения, соответствующих описанному подходу. Как код события загрузки формы form1, так и код события щелчка кнопки button1 вносят изменения, которые влияют на общее состояние формы.

//Код, выполняющийся при загрузке формы

private void Form1_Load(object sender, System.EventArgs e) {

 textBox1.Visible = true;

 listBox1.Visible = false;

}

string m_someImportantInfo;

//Пользователь щелкнул на кнопке, желая перейти к выполнению

//следующего шага, предусмотренного в данном приложении. Скрыть

//текстовое окно и отобразить окно списка в отведенном для этого месте

private void button1_Click(object sender, System.EventArgs e) {

 m_someImportantInfo = textBox1.Text;

 textBox1.Visible = false;

 listBox1.Visible = true;

} 

Подход 2: плановое, централизованное, явное управление состояниями (удачный подход)

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

string m_someImportantInfo;

//Определить состояния, в которых может находиться приложение

enum MyStates {

 step1, step2

}

//Главная функция, которая вызывается

//всякий раз, когда возникает необходимость

//в изменении состояния приложения

void ChangeApplicationState(MyStates newState) {

 switch (newState) {

 case MyStates.step1:

  textBox1.Visible = true;

  listBox1.Visible = false;

  break;

 case MyStates.step2:

  m_someImportantInfo = textBox1.Text;

  textBox1.Visible = false;

  listBox1.Visible = true;

  break;

 }

}

//Пользователь щелкнул на кнопке, желая перейти к выполнению

//следующего шага, предусмотренного в данном приложении. Скрыть

//текстовое окно и отобразить окно списка в отведенном для этого месте

private void button1_Click(object sender, System.EventArgs e) {

 //Вызвать главную функцию, осуществляющую изменение состояния

 ChangeApplicationState(MyStates.step2);

}

//Код, выполняющийся при загрузке формы

private void Form1_Load(object sender, System.EventArgs e) {

 //Вызвать главную функцию, осуществляющую изменение состояния

 ChangeApplicationState(MyStates.step1);

}

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

Краткий ответ на этот вопрос звучит так: "Нет, не должен". Ваш код вовсе не должен быть меньше по размеру, чем аналогичный код для настольных компьютеров — он должен быть лучше! Среди разработчиков мобильных приложений бытует ошибочная точка зрения, согласно которой при написании кода лучше не разбивать его на отдельные функции, а стараться поместить в любую заданную функцию как можно больше кода и как можно чаще использовать встроенный код. Такой подход противоречит устоявшимся принципам проектирования. Назовем эту тенденцию "оптимизацией под микроскопом".

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

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