Шрифт:
Подход 1: зависящее от специфики конкретной ситуации, децентрализованное, неявное управление состояниями (неудачный подход)
Специализированный стиль проектирования, ориентированный на максимально возможный учет специфики конкретной задачи, часто встречается в тех случаях, когда приложение в процессе разработки постепенно усложняется. Различные аспекты состояния приложения изменяются в разных местах приложения. Данные о состоянии хранятся в таких свойствах элементов управления, как Visible, Enabled, Size или Position. Переменные, используемые для хранения ключевой информации о состоянии, изменяются непосредственно в тех строках кода, где это оказывается необходимым, а загрузка данных и освобождение памяти от них распределяются по всему приложению в зависимости от конкретной ситуации. Развитие событий напоминает "перетягивание каната" между различными частями приложения, поскольку каждая из функций делает все необходимое для выполнения возложенных на нее задач, не обращая никакого внимания на остальную часть приложения. Простейшим примером подобного поведения может служить код, реагирующий на такие события пользовательского интерфейса, как щелчок на кнопке, которой соответствует встроенный код, изменяющий состояние приложения. В листинге 5.2 приведен типичный код, встречающийся в классах формы приложения, соответствующих описанному подходу. Как код события загрузки формы form1, так и код события щелчка кнопки button1 вносят изменения, которые влияют на общее состояние формы.
Подход 2: плановое, централизованное, явное управление состояниями (удачный подход)
Явное управление состояниями — прямая противоположность предыдущему подходу. В этом случае любые переходы между состояния реализуются в рамках одной главной функции. В коде обработчика событий, ответственном за изменение некоторого аспекта состояния приложения, это обеспечивается вызовом единственной функции, которая также вызывается любым другим кодом, предназначенным для изменения состояния приложения в соответствии с логикой приложения. Пример реализации такого подхода представлен в листинге 5.3.
В приведенном выше коде решаются те же задачи, что и в предыдущем примере, но при этом последовательно используется инкапсуляция. Вместо того чтобы непосредственно изменять состояние интерфейса, коды обработки событий каждого из элементов пользовательского интерфейса вызывают главную функцию управления состояниями, которая и выполняет всю необходимую работу. Этот процесс легко масштабируется при расширении или изменении приложения. Необходимые изменения любых аспектов функционирования приложения обеспечиваются за счет использования единственной главной функции. По мере возникновения потребности в дополнительных элементах управления или состояниях приложения, они могут без труда включаться в нашу программную модель централизованным способом
Краткий ответ на этот вопрос звучит так: "Нет, не должен". Ваш код вовсе не должен быть меньше по размеру, чем аналогичный код для настольных компьютеров — он должен быть лучше! Среди разработчиков мобильных приложений бытует ошибочная точка зрения, согласно которой при написании кода лучше не разбивать его на отдельные функции, а стараться поместить в любую заданную функцию как можно больше кода и как можно чаще использовать встроенный код. Такой подход противоречит устоявшимся принципам проектирования. Назовем эту тенденцию "оптимизацией под микроскопом".
Оптимизация более высокого порядка реализуются не на микроскопическом уровне, а на макроуровне. Проекты, в которых широко используется инкапсуляция, предоставляют гораздо больше возможностей для макрооптимизации. Имея единственный набор функций, предназначенных для управления приложением, вам будет легче работать со структурой приложения и тем самым оптимизировать ее. Чтобы обеспечить высокую производительность приложения, вам придется возвращаться к уже пройденным стадиям проекта, анализировать их и при необходимости изменять первоначальные предпосылки, которые, как выяснилось впоследствии, оказались неверными. В этом отношении централизованный подход к управлению состояниями приложения принесет вам гораздо больше пользы, чем распределенный специализированный подход.
Существуют и такие ситуации, в которых действительно имеет смысл затратить усилия на оптимизацию отдельных алгоритмов и вынести код за пределы функций, сделав его встроенным. Это, например, может оказаться целесообразным в случае кода, выполняющего интенсивную многократную обработку крупных наборов данных в циклах. При необходимости можно систематически выявлять такие ситуации и принимать соответствующие меры. Однако для конечных автоматов, работающих на уровне приложения, которые вызываются при переходе приложения из одного режима выполнения операций или отображения пользовательского интерфейса в другой, такие ситуации не характерны; указанные изменения обычно осуществляются с низкой частотой и не встречаются внутри плотных циклов.
Наконец, гораздо проще взять инкапсулированный код и вставить его в вызывающую функцию, чем пытаться преобразовать произвольный фрагмент кода к инкапсулированному виду, чтобы повысить эффективность работы с ним. Это вам подтвердит каждый, кому хотя бы раз приходилось заниматься упорядочением кода типа "спагетти", написанного другими разработчиками, приводя его к более удобной в работе инкапсулированной форме!
В силу описанных причин при разработке программного обеспечения для мобильных устройств удачная структура кода играет, по крайней мере, не меньшую роль, чем в случае настольных компьютеров. Использование конечных автоматов облегчает эффективную организацию кода, что в свою очередь способствует созданию замечательных приложений.