Чи вважається ланцюжок подій хорошою практикою?

Час від часу я стикався із сценаріями, коли перед тим, як викликати подію, необхідно виконати кілька складних умов. Крім того, більшість слухачів також проводять додаткові перевірки для визначення ходу дії. Це змусило мене задуматися, чи краще рішення буде думати про менші події, і нехай вони спрацьовують всередині один одного.

Зв'язані події дають мені змогу пізніше залучити будь-яких додаткових слухачів із досить невеликими зусиллями (можливе порушення YAGNI?). Мій код складався з простих легко зрозумілих елементів, які не повинні бути важкими для розуміння оточуючим.

Однак можливими недоліками цього рішення буде той факт, що якщо щось трапиться неправильно в ланцюжку (наприклад, помилка, що викликається помилкою події людини), виявити помилку буде досить важко.

Чи є подія ланцюжком гарною ідеєю ^TM ? Якщо ні, то які альтернативні способи уникнути захаращення коду, пов’язаного з подіями?

Чи хороша ідея ланцюжка подій?

Це одна з тих речей, яка здається дійсно хорошою ідеєю, поки її не використаєш.

Дуже важко налаштувати каскадні події без якоїсь загальної залежності від порядку. Їх важко налаштувати, не викликаючи проблем через нескінченних циклів і випадкових витоків пам'яті. Вони ускладнюють дизайн класу через з'єднання, спричинене подіями, які мають знати як куди прикріплювати, так і куди каскадувати.

І вони дуже важко налагоджують і міркують про код.

Зараз їх іноді можна використовувати у відносно обмежених сценаріях, коли структура коду обмежує деякі з цих проблем. У інтерфейсах інтерфейсу каскадні події можуть бути використані для запускання ієрархії, оскільки така ієрархічна структура допомагає обмежувати проблеми власності та циклічність.

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

Прив'язка подій - це гарна ідея, якщо

• Це, як правило, підходить до вашого сценарію. Простий приклад - дія користувальницького інтерфейсу користувача, що викликає інші візуальні події.
• Кожна подія є самодостатньою та керованою. Ви не хочете, щоб рішення стало занадто громіздким.
• Потік управління легко стежити. Її потрібно реалізувати на платформі та мовою, якою розробник легко може пройти. Якщо вам потрібно відстежити "магічні" методи, щоб простежити, що відбувається, ви йдете неправильним шляхом.

Дуже важливо продумати рішення і узагальнити деякі речі, перш ніж починати будувати систему. Наприклад, мовою ОО ви повинні мати базовий інтерфейс або абстрактний клас як основу для всіх подій. Цей клас повинен містити такі речі, як реєстрація / налагодження. Ви також можете захотіти узагальнений клас управління подіями для вишуканого поводження з помилками.

Якщо говорити з точки зору того, хто колись витратив пару днів на пошук помилки, пов’язаної з ланцюгом подій, це дуже погана ідея (см). Ви ховаєте контрольний потік, який (як ви зазначали) може налагодити кошмар. Ситуація, в якій я опинилася, виникла, коли хтось додав код обробки помилок, який скинув елемент керування. Це призвело до того, що ланцюжок onPropertyChangeобробників перетворив освіжаючий елемент управління, який мав оброблювач помилок, що призвело до того, що він знову скинув інше управління тощо. В основному користувальницький інтерфейс просто зафіксується на центральному процесорі на 100%.

Якщо у вас є якийсь спосіб запобігти спрацьовуванню обробників подій неодноразово для однієї кореневої події, то, можливо, ви зможете цього уникнути, але я можу уявити ситуації, коли ви хочете отримати кілька викликів обробника подій.

Реалізувати колодязь подій складно з усіх причин, про які згадували інші.

Однак це також є основною умовою більшості двигунів правил. JBoss Drools, IBM jRules, PegaSystems, Corticon і FICO Blaze Advisor - це всі основні системи управління бізнес-правилами (BRMS), які дозволяють користувачам оголошувати правила, які вимикаються на основі подій, що відбуваються в системах. Як ланцюг вперед, так і назад можливий і здійсненний.

Мова Пролога та його похідні базуються на одному понятті.

Запропоновані алгоритми не прості, налагодження МОЖЕ бути болем, але в моделі є велика цінність.

Один з потенційних недоліків полягає в тому, що випадково закінчити оновлення оновлень досить просто. наприклад A -> B -> C -> A -> B ...

Інший підхід полягає у створенні складених подій, які відповідають за звільнення послідовності подій. Це означає, що ви не повинні зациклюватися на циклі, і ви отримуєте єдине місце для лову помилок / тощо. Я мав певний успіх у цьому, хоча, правда, не використовував його для нічого особливо складного (поки!).