Какой паттерн проектирования применяют для построения событийной системы?
Подскажите какой паттерн применяют при построении систем, основанных на событиях? Всякие там event'ы и иже с ними. Я представляю себе, что это observer. Но у меня возникает вопрос, на который я сам не могу найти ответ: если обработка одного события порождает другое событие (а может и не одно) не может ли это иметь эффект лавины, когда обрабатывая события система породит событий больше, чем обрабатывает? Например система автоматизации, измерив какой-нибудь параметр(например температуру или давление), воздействует на некий орган управления (например на задвижку или кран), что в свою очередь порождает событие воздействия на орган управления (какой-нибудь onZakrytieKrana()), и вызывает обработчик этого события. Это обработчик воздействует на другие органы управления (например отключает генератор или выключает компрессор), каждый из которых порождает своё такое-же событие (типа onGeneratorOff() или onKopressorOff() ) и т.д. Получится такой себе бесконечный цикл порождения и обработки событий. Или может есть какие-нибудь правила и ограничения при построении подобных систем? Например код обработчика не должен выполнять код, порождающий новое событие. А может я совсем неправильно представляю работу событийной системы? Помогите пожалуйста разобраться.
NSliM, все происходит именно так, как ты описываешь. События генерируются целыми кластерами скопом или порождаются цепочками причин и следствий. Какие проблемы ты видишь в этом?
Евгений Шатунов, проблема может быть в невнимательности. Мне кажется, что если количество событий станет очень велико, то может получится так, обработчик первого события вызовет второе событие, второй обработчик вызовет третье, а третий обработчик вызовет первое событие, и замкнет цепочку в бесконечный цикл. Такое возможно?
NSliM, да, такое возможно. На этом уровне, обычно, оформляются детекторы циклов, анализаторы цепочек вложенности и прочие инструменты отладки событийных систем.
Относительно IoT или АСУ во внимание следует принимать что эти системы являются высококонкурентными и сильно распределенными. Брокер в АСУ не замирает в ожидании завершения события, он только отправляет сообщение о действии в контролер и принимает сообщение о выполнении действия. IoT тоже живет полностью параллельно, брокер там занимается только приемом входящих и генерацией исходящих событий.
Вообще тебе стоит изучить два базовых архитектурных шаблона для событийных систем: Reactor и Proactor.
Эти шаблоны проектирования реализуются через шаблоны дизайна, такие как Push/Pull, Observer/Publisher-Subscriber, Command и Pipe. Могут использоваться и другие шаблоны, эти шаблоны я сейчас вперед всего вспоминаю.
Посмотри на Actor Model как на общую архитектуру реализации событийной системы.
Простой
Средний
Простой
Простой
Простой
