В компьютерном программировании событийно -управляемое программирование — это парадигма программирования , в которой поток программы определяется внешними событиями . События пользовательского интерфейса от мышей , клавиатур , сенсорных панелей и сенсорных экранов , а также внешние входы датчиков являются обычными случаями. События также могут быть сгенерированы программно, например, из сообщений от других программ , уведомлений от других потоков или других сетевых событий.
Событийно-управляемое программирование является доминирующей парадигмой, используемой в приложениях графического пользовательского интерфейса и сетевых серверах.
В событийно-управляемом приложении обычно имеется цикл событий , который прослушивает события, а затем запускает функцию обратного вызова при обнаружении одного из этих событий.
Программы, управляемые событиями, можно писать на любом языке программирования , хотя эта задача упрощается на языках, которые предоставляют абстракции высокого уровня .
Хотя они не совсем соответствуют событийно-управляемой модели, обработка прерываний и обработка исключений имеют много общего.
Важно различать парадигмы, управляемые событиями и управляемые сообщениями (т. е. управляемые очередями) : сервисы, управляемые событиями (например, AWS SNS ), отделены от своих потребителей. В то время как сервисы, управляемые очередями/сообщениями (например, AWS SQS ), связаны со своими потребителями. [1]
Поскольку цикл обработки событий , включающий извлечение/отправку событий, широко распространен в приложениях, многие среды программирования берут на себя его реализацию и ожидают от пользователя предоставления только кода для обработчиков событий.
RPG , ранний язык программирования от IBM , концепция дизайна которого в 1960-х годах была похожа на описанное выше событийное программирование, предоставлял встроенный основной цикл ввода-вывода (известный как «программный цикл»), в котором вычисления реагировали в соответствии с «индикаторами» ( флагами ), которые были установлены ранее в цикле.
Фактическая логика содержится в процедурах обработки событий. Эти процедуры обрабатывают события, на которые будет реагировать основная программа. Например, один щелчок левой кнопкой мыши по кнопке команды в программе с графическим интерфейсом может запустить процедуру, которая откроет другое окно, сохранит данные в базе данных или завершит работу приложения. Многие IDE предоставляют программисту шаблоны событий графического интерфейса, позволяя ему сосредоточиться на написании кода события.
Отслеживание истории обычно тривиально в последовательной программе. Поскольку обработчики событий выполняются в ответ на внешние события, правильная структуризация обработчиков для работы при вызове в любом порядке может потребовать особого внимания и планирования в программе, управляемой событиями.
Помимо написания обработчиков событий, обработчики событий также должны быть привязаны к событиям, чтобы при возникновении события вызывалась правильная функция. Для событий пользовательского интерфейса многие IDE объединяют два шага: двойной щелчок по кнопке, и редактор создает (пустой) обработчик событий, связанный с нажатием кнопки пользователем, и открывает текстовое окно, чтобы вы могли редактировать обработчик событий.
Большинство существующих архитектур GUI используют событийно-управляемое программирование. [2] Windows имеет цикл событий . Фреймворк Java AWT обрабатывает все изменения пользовательского интерфейса в одном потоке, называемом потоком диспетчеризации событий . Аналогично, все обновления пользовательского интерфейса в фреймворке JavaFX происходят в потоке приложения JavaFX. [3]
Большинство сетевых серверов и фреймворков, таких как Node.js, также управляются событиями. [4]
сцены JavaFX, представляющий графический пользовательский интерфейс приложения JavaFX, не является потокобезопасным и может быть доступен и изменен только из потока пользовательского интерфейса, также известного как поток приложения JavaFX.