Считается ли цепочка событий хорошей практикой?

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

Последовательность событий позволила бы мне вплетать в себя дополнительных слушателей позже с довольно небольшими усилиями (возможное нарушение YAGNI?). Мой код будет состоять из простых легко понятных элементов, которые не должны быть трудными для понимания другими.

Тем не менее, возможными недостатками этого решения может быть тот факт, что если что-то случится с ошибкой в ​​цепочке (например, ложное срабатывание события из-за человеческой ошибки), будет довольно сложно уловить ошибку.

Является ли мероприятие цепочкой хорошей идеи ^ТМ ? Если нет, то каковы альтернативные методы, чтобы код, связанный с событиями, был загроможден?

Является ли событие цепочкой хорошей идеей?

Это одна из тех вещей, которая кажется действительно хорошей идеей, пока вы ее не используете.

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

И они очень трудны для отладки и рассуждений о коде.

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

Тем не менее, в наши дни я гораздо чаще принимаю делегат в конструкторе для такого рода расширяемого поведения, чем позволяю произвольному поведению зафиксироваться во время выполнения.

Цепочка событий - хорошая идея, если

• Как правило, это соответствует вашему сценарию. Простой пример - действие пользовательского интерфейса, запускающее другие визуальные события.
• Каждое событие является автономным и управляемым. Вы не хотите, чтобы решение стало слишком громоздким.
• Поток контроля легко следовать. Это должно быть реализовано на платформе и на языке, который легко понять разработчику. Если вам нужно отследить «магические» методы, чтобы отслеживать происходящее, вы идете по неверному пути.

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

Говоря с точки зрения человека, который когда-то потратил пару дней на отслеживание ошибки, связанной с цепочкой событий, это очень плохая идея (см). Вы скрываете свой поток управления, который (как вы заметили) может сделать отладку кошмаром. Ситуация, в которой я находился, возникла, когда кто-то добавил код обработки ошибок, который сбрасывал элемент управления. Это привело к появлению цепочки onPropertyChangeобработчиков, обновляющих элемент управления с обработчиком ошибок, что привело к его повторному сбросу другого элемента управления и т. Д. По сути, пользовательский интерфейс просто блокируется с привязкой процессора к 100%.

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

Хорошо реализовать цепочку событий по всем причинам, упомянутым другими.

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

Язык Пролог и его производные основаны на одном и том же понятии.

Используемые алгоритмы не просты, отладка МОЖЕТ быть трудной, но в модели есть много полезного.

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

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