Что понимают под событийным программированием

§ 4. Объектно-событийная модель работы программы

Оглавление

4.1. Элементы управления в приложениях с графическим интерфейсом

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

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

Операционные системы с графическим оконным интерфейсом (например, Windows) предполагают общение пользователя с программой посредством элементов управления. К элементам управления относят: кнопки, разнообразные меню, текстовые сообщения, списки и др. При работе программы пользователь выбирает какой-либо элемент управления и совершает с ним определенное действие (пример 4.1). Если такое действие для выбранного элемента было определено, то программа его выполняет, иначе выдает сообщение об ошибке.

Многие системы программирования позволяют создавать программы с оконным интерфейсом. Такие программы называют оконными приложениями (Windows Form Application). Создаются они как проект и состоят из нескольких файлов. Вешний вид окна будущего приложения строится на форме. Для формы сохраняются два файла — один содержит описание внешнего вида формы, другой — описание действий при выборе пользователем того или иного элемента управления. Главный файл проекта содержит описание его структуры, а также команды по созданию формы и запуску приложения.

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

Визуальное программирование поддерживается в PascalABC и Delphi (код пишется на языке Pascal), VisualBasic, C# и др. (пример 4.2). Для обучения учащихся младших классов используется визуальное программирование в среде Скретч (Scratch).

Код на языке программирования С++ можно писать в таких средах визуального программирования, как C++Builder, Qt и др.

Многие элементы управления в разных средах имеют одинаковые или синонимичные имена (пример 4.3).

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

Пример 4.2. Среды программирования, в которых реализована поддержка парадигмы визуального программирования.

VBA (Visual Basic for Applications):

Visual Studio для языка C#:

Основателем RAD считается сотрудник IBM британский консультант по информационным технологиям Джеймс Мартин (1933 — 2013), который в начале 1990-х гг. сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. Технолгия RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за короткий срок.

Пример 4.3. Основные элементы интерфейса:

Источник

Событийно-ориентированное программирование

Шаблон: Просмотр • англ. event-driven programming ; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).

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

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

Содержание

Сфера применения

Событийно-ориентированное программирование, как правило, применяется в трех случаях:

Применение в серверных приложениях

Событийно-ориентированное программирование применяется в серверных приложениях для решения проблемы масштабирования на 10000 одновременных соединений и более.

В серверах, построенных по модели «один поток на соединение», проблемы с масштабируемостью возникают по следующим причинам:

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

Мультиплексирование

Для мультиплексирования соединений могут быть использованы следующие средства операционной системы:

Примеры реализаций

Применение в настольных приложениях

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

Обработчик события может выглядеть следующим образом (на примере C#):

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

Языки программирования

В языке C# события реализованы как элемент языка и являются членами классов. Механизм событий здесь реализует шаблон проектирования Publisher/Subscriber. Пример объявления события:

Разные языки программирования поддерживают СОП в разной степени. Наиболее полной поддержкой событий обладают следующие языки (неполный список):

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

Инструменты и библиотеки

См. также

Англоязычные источники

Материалы на русском

Ссылки

Полезное

Смотреть что такое «Событийно-ориентированное программирование» в других словарях:

Событийно-управляемое программирование — объектно ориентированное программирование, при котором задаются реакции программы на различные события. См. также: Объектно ориентированное программирование Финансовый словарь Финам … Финансовый словарь

Объектно-ориентированное программирование — Эта статья во многом или полностью опирается на неавторитетные источники. Информация из таких источников не соответствует требованию проверяемости представленной информации, и такие ссылки не показывают значимость темы статьи. Статью можно… … Википедия

Аспектно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Субъектно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Компонентно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Событийно-ориентированная архитектура — Архитектура, управляемая событиями (Event driven architecture EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события. Событие можно определить как «существенное… … Википедия

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

Автоматное программирование — Автоматное программирование это парадигма программирования, при использовании которой программа или её фрагмент осмысливается как модель какого либо формального автомата. В зависимости от конкретной задачи в автоматном программировании… … Википедия

Отражение (программирование) — У этого термина существуют и другие значения, см. Отражение. Для улучшения этой статьи желательно?: Перевести текст с иностранного языка на русский. Н … Википедия

Структурное программирование — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей … Википедия

Источник

Как событийно-ориентированная архитектура решает проблемы современных веб-приложений

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

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

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

Актуальные проблемы современного веба

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

Доступность

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

Масштабируемость

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

Единый источник истины

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

Синхронность

При реализации типичного сценария вида «запрос-отклик» клиент дожидается, пока ответит сервер; он блокирует все действия, пока не получит ответ, либо пока не истечет заданная задержка. Если взять такое поведение и внедрить его в микросервисную архитектуру при помощи цепочек вызовов, пронизывающих всю систему, то можно легко оказаться в так называемом «микросервисном аду». Все начинается с вызова всего одного сервиса, назовем его «сервис А». Но затем сервис A должен вызвать сервис B, и начинается самое интересное. Проблема с данным поведением такова: если сам сервис связан с заблокированными ресурсами (например, висит поток), то задержки растут экспоненциально. Если у нас разрешена задержка в 500 мс на сервис, а в цепочке пять вызовов сервисов, то первому сервису понадобится задержка в 2500 мс (2,5 секунды), а последнему – 500 мс.

Вызовы современного веба

Знакомство с событийно-ориентированной архитектурой

Событийно-ориентированная архитектура (EDA) – это парадигма программной архитектуры, способствующая порождению, обнаружению, потреблению событий и реакции на них.

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

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

Если подумать над некоторыми событиями, то по поводу некоторых сразу понятно, что они важны для бизнеса, а по поводу некоторых – нет. Особенно по поводу тех, что происходят в ответ на другие события. Для выявления событий, идущих через систему, применяется техника под названием «событийный штурм». Созываются участники разработки приложения (от программистов до разработчиков бизнес-логики и экспертов в предметной области) и общими силами картируют все бизнес-процессы, представляя их в виде конкретных событий. Когда такая карта будет готова, результат работы формулируется в виде требований, которые должны выполняться при разработке приложений.

Пример приложения для бронирования, описанного методом событийного штурма

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

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

События происходят в результате действия, поэтому целевой системы здесь нет; нельзя сказать, что сервис A инициирует события в сервисе B; но можно сказать, что сервис B интересуют события, порождаемые сервисом A. Правда, в этой системе могут быть и другие «заинтересованные стороны», например, сервисы C или D.

Как же нам убедиться, что событие, инициированное в некоторой системе, достигнет всех «заинтересованных» сервисов? Как правило, подобные системы решаются при помощи брокеров сообщений. Брокер – это просто приложение, действующее в качестве посредника между генератором события (приложением, создавшим это событие) и потребителем события. Таким образом, приложения удается аккуратно открепить друг от друга, позаботившись о проблеме доступности, речь о которой шла выше в этом посте. Если именно в данный момент приложение недоступно, то, вернувшись в онлайн, оно начнет потреблять события и обрабатывать их, наверстав все те события, которые успели произойти за период, пока оно оставалось недоступным.

Что насчет хранилища данных? Можно ли хранить события в базе данных, либо вместо базы данных требуется что-то иное? Определенно, события можно хранить в базах данных, но в таком случае утрачивается их «событийная» сущность. Как только событие произошло, скорректировать его мы уже не можем, поэтому события по сути своей неизменяемы. Базы данных, в свою очередь… изменяемы, после занесения данных в базу их вполне можно изменить.

Лучше хранить события в логах событий. Логи событий – не что иное, как централизованное хранилище данных, где каждое событие записано в виде последовательности неизменяемых записей, так называемого «лога». Лог можно сравнить с журналом, где каждое новое событие добавляется в конец списка. Всегда можно воссоздать наиболее актуальное состояние, воспроизведя все события лога от начала до настоящего момента.

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

Единственным исключением из этого принципа являются сервисы, предназначенные для создания материализованных представлений. В сущности, материализованное представление – это состояние, описывающее лог событий в определенный момент времени. Такой подход используется, чтобы было проще запрашивать данные. Возвращаясь к проблеме масштабирования, скажем, что материализованное представление – это просто совокупное представление событий, напоминающее по форме таблицу; но где мы храним эти таблицы? Чаще всего приходится видеть такие агрегации в памяти, и при этом наш сервис автоматически превращается в сохраняющий состояние. Быстрое и легкое решение – снабдить локальной базой данных каждый сервис, создающий материализованные представления. Таким образом, состояние хранится в базе данных, и сервис работает без сохранения состояния.

Хотя, событийно-ориентированная архитектура существует уже более 15 лет, она лишь недавно снискала серьезную популярность, и это неслучайно. Большинство компаний проходят этап «цифровой трансформации», сопровождаемый дикими требованиями. Из-за сложности этих требований инженерам приходится осваивать новые подходы к проектированию ПО, предполагающие, в частности, ослабление связанности сервисов друг с другом и снижение издержек на обслуживание сервисов. EDA — одно из возможных решений этих проблем, но не единственное. Также не рассчитывайте, что все проблемы решатся, стоит только перейти на EDA. Для реализации некоторых фич по-прежнему могут потребоваться надежные дедовские REST API или хранение информации в базе данных. Выберите наиболее подходящий для вас вариант и спроектируйте его как следует!

Источник

Событийно-ориентированное программирование

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

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

Содержание

Сфера применения

Событийно-ориентированное программирование, как правило, применяется в трех случаях:

Применение в серверных приложениях

Событийно-ориентированное программирование применяется в серверных приложениях для решения проблемы масштабирования на 10000 одновременных соединений и более.

В серверах, построенных по модели «один поток на соединение», проблемы с масштабируемостью возникают по следующим причинам:

Философской предпосылкой для отказа от потоковой модели серверов может служить высказывание Алана Кокса: «Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы» [1]

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

Мультиплексирование

Для мультиплексирования соединений могут быть использованы следующие средства операционной системы:

Источник

Объектно-событийное программирование (ООП-2)

История возникновения ОСП

Другим фундаментальным понятием является класс.

Следующими важнейшими принципами ООП являются наследование и полиморфизм.

Другим важнейшим принципом ООП является модульность.

Развитием объектно-орниентированной парадигмы (методологии), стала объектно-событийная парадигма, опирающаяся на понятия объекта и события. Эта парадигма позволяет конструировать, программировать распределенные вычислительные среды, в том числе среды реального времени, SCADA и пр.

Первый ряд примеров событий доставляет собственно сам жизненный цикл объекта:

Более сложные примеры событий возникают тогда, когда у объекта появляются внутренние состояния, которые описываются соответствующей диаграммой переходов (из одного состояния в другое).

Современными языками объектно-ориентированного программирования являются С++ и Java. С середины 90-х годов многие объектно–ориентированные языки реализуются как системы визуального программирования, в которых интерфейсная часть программного продукта создается в диалоговом режиме, практически без написания программных операторов. К объектно – ориентированным системам визуального проектирования относятся Visual Basic, Delphi, C++ Builder, Visual C++. Язык VBA (Visual Basic for Applications) – язык приложений Microsoft Office (Excel, Word, Access, Power Point и др). VBA соблюдает основной синтаксис языка и правила программирования языков Basic – диалектов, позволяет создавать макросы для автоматизации выполнения некоторых операций и графический интерфейс пользователя, интеграцию между различными программными продуктами.

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

Лабораторные работы

Литература

Источник