События

Кто в ответе?

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

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

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

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

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

Эти роли не являются исключительными, поскольку некоторые подписчики могут включать собственные события. Заметьте, "событие" является программной концепцией: даже когда события возбуждаются вне ПО — нажатие кнопки мыши, измерение датчика, прибытие сообщения, — для того чтобы быть обработанными, они должны транслироваться в программные события. ПО может включать свои собственные события, не связанные с внешними воздействиями.

Программирование, управляемое событиями, применимо во многих различных областях. Оно с успехом применяется в графическом интерфейсе пользователя — GUI, что и станет нашим первым примером.

Управляемое событиями GUI-программирование

Старый добрый ввод:

Рис. 7.1.

До появления GUI программы вводили данные, приходящие от некоторого последовательного посредника, например, программа могла читать последовательность строк, обрабатывая каждую из них соответствующим образом:

from
  read_line
  count : = 0
until
  exhausted
loop
  count := count + 1
    — Сохранить last_line в позиции count в Result:
Result [count] := last_line
  read_line
end

Здесь read_line пытается читать следующую строку ввода, сохраняя ее в last_line, а значение exhausted принимает значение true, если при выполнении read_line нет больше строк для ввода.

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

Современный интерфейс

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

Рассмотрим приведенный далее снимок экрана. Он иллюстрирует стек переполнения, возникшего из-за бесконечной рекурсии при выполнении программы в EiffelStudio. Сам пример не имеет значения — все современные среды разработки, использующие GUI, похожи. Интерфейс пользователя включает элементы управления : текстовые поля, кнопки, меню, таблицы и другие.

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

Но какое действие будет первым, и случится ли вообще хоть что-нибудь?

увеличить изображение
Рис. 7.2. Интерфейс программы

Мы не знаем.

Конечно, мы могли бы использовать большой оператор if... then ... elseif... end или конструкцию выбора со многими ветвями, перечисляя все возможности:

inspect
  user_action
when "Нажата кнопка Stop" then
  "Завершить выполнение"
when "Введен текст в поле Class Name" then
"В соответствующее окно (слева вверху) вывести текст класса, имя которого
задано в текстовом поле"
when    …Другие ветви…
end

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

Проектирование, управляемое событиями ("издатели-подписчики"), предлагает в такой ситуации совсем другую схему.

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

Рис. 7.3. Включение и обработка событий

Стиль "Издатели-подписчики" полезен в различных областях приложения: GUI-программирование — это просто один из примеров. Другие примеры:

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