¿El encadenamiento de eventos se considera una buena práctica?

De vez en cuando me encuentro con escenarios en los que se deben cumplir varias condiciones complejas antes de desencadenar un evento. Además, la mayoría de los oyentes también realizan verificaciones adicionales para determinar el curso de acción. Esto me hizo pensar si una mejor solución sería pensar en términos de eventos más pequeños y dejar que se disparen uno dentro del otro.

El encadenamiento de eventos me permitiría tejer más oyentes adicionales más adelante con un esfuerzo bastante bajo (¿posible violación de YAGNI?). Mi código consistiría en elementos simples y fáciles de entender, que no deberían ser difíciles de entender para otros.

Sin embargo, los posibles inconvenientes de esta solución sería el hecho de que si algo saliera mal en la cadena (por ejemplo, la activación de un evento falso debido a un error humano), sería bastante difícil detectar el error.

¿Cadena de eventos es una buena idea ^TM ? Si no es así, ¿cuáles son los métodos alternativos para mantener el código relacionado con el evento abarrotado?

¿Cadena de eventos es una buena idea?

Es una de esas cosas que parece una muy buena idea, hasta que la usas.

Es muy difícil configurar eventos en cascada sin algún tipo de dependencia implícita en el orden. Es difícil configurarlos sin causar problemas debido a bucles infinitos y fugas ocasionales de memoria. Hacen que el diseño de la clase sea más difícil debido al acoplamiento causado por eventos que necesitan saber dónde conectarse y dónde conectarse en cascada.

Y son muy difíciles de depurar y razonar sobre el código.

Ahora a veces se pueden usar en escenarios relativamente limitados donde la estructura del código limita algunos de estos problemas. En las interfaces de usuario, los eventos en cascada se pueden usar para activar la jerarquía porque esa estructura jerárquica ayuda a limitar la propiedad y los problemas de bucle.

Aún así, encuentro con mucha más frecuencia en estos días que acepto un delegado en un constructor para ese tipo de comportamiento extensible que dejar que el comportamiento arbitrario se enganche en el tiempo de ejecución.

El encadenamiento de eventos es una buena idea si

• Generalmente es apropiado para su escenario. Un ejemplo simple es la acción de la IU de un usuario que desencadena otros eventos visuales.
• Cada evento es autónomo y manejable. No quieres que la solución se vuelva demasiado engorrosa.
• El flujo de control es fácil de seguir. Debe implementarse en una plataforma y en un lenguaje que sea fácil de recorrer para un desarrollador. Si necesita rastrear métodos "mágicos" para rastrear lo que está sucediendo, está yendo por el camino equivocado.

Es muy importante pensar en la solución y generalizar algunas cosas antes de comenzar a construir el sistema. Por ejemplo, en un lenguaje OO, debe tener una interfaz básica o una clase abstracta como base para todos los eventos. Esa clase debería incorporar cosas como el registro / depuración. También es posible que desee una clase de administración de eventos generalizada para manejar fallas con gracia.

Hablando desde el punto de vista de alguien que una vez pasó un par de días rastreando un error relacionado con la cadena de eventos, esta es una muy mala idea (sm). Está ocultando su flujo de control que (como notó) puede hacer que la depuración sea una pesadilla. La situación en la que estaba surgió cuando alguien agregó un código de manejo de errores que restableció un control. Esto condujo a una cadena de onPropertyChangecontroladores que terminaron refrescando el control que tenía el controlador de errores, lo que llevó a restablecer el otro control nuevamente, y así sucesivamente. Básicamente, la interfaz de usuario simplemente se bloquearía con la CPU vinculada al 100%.

Si tiene alguna forma de evitar que los controladores de eventos se activen más de una vez para el mismo evento raíz, entonces puede evitar esto, pero puedo imaginar situaciones en las que podría querer invocaciones de controladores de eventos múltiples.

Implementar el encadenamiento de eventos bien es difícil, por todas las razones mencionadas por otros.

Sin embargo, también es la premisa básica de la mayoría de los motores de reglas. JBoss Drools, IBM jRules, PegaSystems, Corticon y FICO Blaze Advisor son los principales sistemas de gestión de reglas de negocios (BRMS) que permiten a los usuarios declarar reglas que se disparan en función de los eventos que ocurren en los sistemas. Tanto el encadenamiento hacia adelante como hacia atrás son posibles y factibles.

El lenguaje Prolog y sus derivados se basan en la misma noción.

Los algoritmos involucrados no son simples, la depuración PUEDE ser una molestia, pero hay mucho valor en el modelo.

Un inconveniente potencial es que es bastante fácil terminar accidentalmente con actualizaciones en bucle. por ejemplo, A -> B -> C -> A -> B ...

Otro enfoque es crear eventos compuestos que son responsables de disparar una secuencia de eventos. Esto significa que no debe terminar atrapado en un bucle y le brinda un solo lugar para detectar errores, etc. He tenido cierto éxito con esto, aunque ciertamente no lo he usado para nada particularmente complicado (¡todavía!).