суббота, 20 сентября 2014 г.

Ссылка. DelphiEventBus

https://github.com/BitecSPB/DelphiEventBus

"Implementation of event bus pattern for Delphi XE
EventBus предназначен для обеспечения взаимодействия между различными компонентами, без повышения связанности."

Вдогонку - Разрабатываем. Тестируем. Наблюдаем

10 комментариев:

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Каждый кто писал 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

    ОтветитьУдалить
    Ответы
    1. Не стал бы я конечно EventBus переоценивать.

      Удалить
    2. «Каждый кто писал Swing-овые или любые другие UI-приложения скорее всего сталкивался с проблемой когда установка галочки на третьем по глубине вложенности модальном окне сильно влияет на ход событий в основном окне.»
      -- Гм... "Swing-овые" приложения создавать не приходилось, но "любые другие UI-приложения" - более чем.
      В контексте вложенных модальных окон (эта тема у нас хорошо изучена) доводилось сталкиваться с другими вопросами, но *никогда* не с обозначенным Вами.
      Иными словами, возникали вопросы относительно того, как получить/учесть контекст, в котором открыта модальная форма, поскольку соответствующий ей код практически изолирован от того, что происходит "снаружи" её. Т.е. совсем непонятно, как модальная (!) форма может влиять на "ход событий в основном окне" (как я понимаю, в окне, действия в котором в итоге привели к открытию этой формы).
      Если не затруднит - проясните немного, о чём идёт речь.

      Удалить
  3. Я лишь привёл цитату автора. Сам он в комментарии(из ссылки) дает пояснение:
    ну "на третьем по глубине вложенности модальном окне" - это только аллегория ситуации. Суть в том что иерархия слушателей иногда имеет место быть весьма и весьма глубокой.

    ОтветитьУдалить
  4. Понятно. Спасибо за ответ.

    «Я лишь привёл цитату автора. Сам он в комментарии(из ссылки) дает пояснение...»
    -- К сожалению, ссылка ведёт на SourceForge, комментарий о котором Вы говорите, вероятно расположен здесь...

    По-существу.
    Вы знаете, такое уже было... В Turbo Vision схема рассылки сообщений (evBroadcast, Message, HandleEvent) была IMHO весьма идейно близкой. Правда там была не "шина" в чистом виде (нечто вроде линейного списка), а скорее дерево (компонент с подкомпонентами, причём тщательно отрабатывалась иерархичность обработки), но в остальном - очень похоже, в частности фильтры (EventMask, Command).
    Эта схема вполне успешно работала, но там были вопросы к производительности: все события идут через одну структуру данных, а при большой номенклатуре типов событий такая "шина" в большей степени занимается фильтрацией, нежели передачей управления обработчикам. Кроме того, в процессе рассылки события приходится всегда полностью проходить весь список обработчиков, поскольку наперёд неизвестно, каким из них придётся передавать управление.
    В большинстве ситуаций это, вероятно не критично, но в общем случае сбрасывать со счетов эти особенности — IMHO опасно.
    Интересно, что нечто похожее есть в старших версиях Delphi (те, которые XE) "из коробки" — см. FMX.Notification.pas.
    Сам же в качестве удачной альтернативы Event Bus, когда она уместна разумеется, предпочитаю AppEventList.

    ОтветитьУдалить
    Ответы
    1. Про окна "модальные" и "не очень" вы правильно написали. "Т.е. совсем непонятно, как модальная (!) форма может влиять на "ход событий в основном окне""

      Окна они должны быть изолированы. Т.е. вход/выход. Ну "на крайний случай" окно влияет на данные, а данные влияют на "остальные View". Т.е. конечно тот же Publisher/subscriber, но "специализированный", а не "общая шина".

      "Общая шина" - ИМХО - это путь к "швейцарским ножам" и "излишней гибкости". И (как следствие) к излишним накладным расходам.

      Удалить
    2. Опять же - ИМХО.

      Для себя лично я вижу ценность "чего-то типа EventBus" только для нужд "логирования".

      Но это опять же - "несколько в сторону".

      Удалить
    3. "Суть в том что иерархия слушателей иногда имеет место быть весьма и весьма глубокой."

      -- об этом мы с вами как-нибудь поговорим (@Ingword).

      Удалить