https://github.com/BitecSPB/DelphiEventBus
"Implementation of event bus pattern for Delphi XE
EventBus предназначен для обеспечения взаимодействия между различными компонентами, без повышения связанности."
Вдогонку - Разрабатываем. Тестируем. Наблюдаем
"Implementation of event bus pattern for Delphi XE
EventBus предназначен для обеспечения взаимодействия между различными компонентами, без повышения связанности."
Вдогонку - Разрабатываем. Тестируем. Наблюдаем
Этот комментарий был удален автором.
ОтветитьУдалитьКаждый кто писал Swing-овые или любые другие UI-приложения скорее всего сталкивался с проблемой когда установка галочки на третьем по глубине вложенности модальном окне сильно влияет на ход событий в основном окне.
ОтветитьУдалитьПроще говоря - ввод пользователя сильно влияет на то как дальше себя будет вести приложение.
Стандартным решением данного вопроса является создание иерархии listener-ов и протаскивание ее через код.
Этот подход работает, однако количество таких классов во времени будет расти, равно как и структурная эрозия кода, создаваемая ими. Можно конечно натянуть на это все DI/IoC - но тогда придется объяснять IoC/DI куда какие listener-ы подсовывать, то есть проблема просто переезжает из одного места в другое.
Лучом надежды, ИМХО, является паттерн Event Bus - одна из моделей реализации паттерна Publisher-Subscriber.
Суть заключается в том что все, абсолютно все типы событий пропускаются через одну шину, которая принимает внутрь себя все, и сама выполняет роль диспетчера.
При таком подходе через DI/IoC нужно протащить только саму шину, ну и зарегистрировать в ней все типы событий - от этого никуда не деться.
Получается чуть более аккуратно, но вполне возможно и более "прямо", проще отлаживать.
Это все только мои теоретические прикидки - будет случай попробую на практике.
http://test-failed.blogspot.com/2012/05/guava-event-bus.html
http://alextretyakov.blogspot.com/2011/11/osnovy-raboty-s-gwt-eventbus.html
Не стал бы я конечно EventBus переоценивать.
Удалить«Каждый кто писал Swing-овые или любые другие UI-приложения скорее всего сталкивался с проблемой когда установка галочки на третьем по глубине вложенности модальном окне сильно влияет на ход событий в основном окне.»
Удалить-- Гм... "Swing-овые" приложения создавать не приходилось, но "любые другие UI-приложения" - более чем.
В контексте вложенных модальных окон (эта тема у нас хорошо изучена) доводилось сталкиваться с другими вопросами, но *никогда* не с обозначенным Вами.
Иными словами, возникали вопросы относительно того, как получить/учесть контекст, в котором открыта модальная форма, поскольку соответствующий ей код практически изолирован от того, что происходит "снаружи" её. Т.е. совсем непонятно, как модальная (!) форма может влиять на "ход событий в основном окне" (как я понимаю, в окне, действия в котором в итоге привели к открытию этой формы).
Если не затруднит - проясните немного, о чём идёт речь.
Я лишь привёл цитату автора. Сам он в комментарии(из ссылки) дает пояснение:
ОтветитьУдалитьну "на третьем по глубине вложенности модальном окне" - это только аллегория ситуации. Суть в том что иерархия слушателей иногда имеет место быть весьма и весьма глубокой.
Понятно. Спасибо за ответ.
ОтветитьУдалить«Я лишь привёл цитату автора. Сам он в комментарии(из ссылки) дает пояснение...»
-- К сожалению, ссылка ведёт на SourceForge, комментарий о котором Вы говорите, вероятно расположен здесь...
По-существу.
Вы знаете, такое уже было... В Turbo Vision схема рассылки сообщений (evBroadcast, Message, HandleEvent) была IMHO весьма идейно близкой. Правда там была не "шина" в чистом виде (нечто вроде линейного списка), а скорее дерево (компонент с подкомпонентами, причём тщательно отрабатывалась иерархичность обработки), но в остальном - очень похоже, в частности фильтры (EventMask, Command).
Эта схема вполне успешно работала, но там были вопросы к производительности: все события идут через одну структуру данных, а при большой номенклатуре типов событий такая "шина" в большей степени занимается фильтрацией, нежели передачей управления обработчикам. Кроме того, в процессе рассылки события приходится всегда полностью проходить весь список обработчиков, поскольку наперёд неизвестно, каким из них придётся передавать управление.
В большинстве ситуаций это, вероятно не критично, но в общем случае сбрасывать со счетов эти особенности — IMHO опасно.
Интересно, что нечто похожее есть в старших версиях Delphi (те, которые XE) "из коробки" — см. FMX.Notification.pas.
Сам же в качестве удачной альтернативы Event Bus, когда она уместна разумеется, предпочитаю AppEventList.
Ну да. Как-то так.
УдалитьПро окна "модальные" и "не очень" вы правильно написали. "Т.е. совсем непонятно, как модальная (!) форма может влиять на "ход событий в основном окне""
УдалитьОкна они должны быть изолированы. Т.е. вход/выход. Ну "на крайний случай" окно влияет на данные, а данные влияют на "остальные View". Т.е. конечно тот же Publisher/subscriber, но "специализированный", а не "общая шина".
"Общая шина" - ИМХО - это путь к "швейцарским ножам" и "излишней гибкости". И (как следствие) к излишним накладным расходам.
Опять же - ИМХО.
УдалитьДля себя лично я вижу ценность "чего-то типа EventBus" только для нужд "логирования".
Но это опять же - "несколько в сторону".
"Суть в том что иерархия слушателей иногда имеет место быть весьма и весьма глубокой."
Удалить-- об этом мы с вами как-нибудь поговорим (@Ingword).