From time to time I've encountered scenarios where several complex conditions need to be met prior to triggering an event. Furthermore, most listeners also run additional checks to determine the course of action. This got me thinking whether a better solution would be to think in terms of smaller events and let them trigger inside each other.Chaining events would allow me to weave in any additional listeners later on with fairly low effort (possible violation of YAGNI?). My code would consist of simple easily understood elements, which shouldn't be difficult for others to understand.However, the possible downsides to this solution would be the fact that should something happen to go wrong in the chain (e.g false event triggering due to human error), it would be quite difficult to catch the bug.Is event chaining a good ideaTM? If not, what are the alternative methods to keep event related code getting cluttered?
Is event chaining considered good practice?
event programming
Is event chaining a good idea?It's one of those things that seems like a really good idea, until you use it. It is very difficult to set up cascading events without some sort of implied dependency on order. It's difficult to set them up without causing issues due to infinite loops and occasional memory leaks. They make class design more difficult due to coupling caused by events needing to know both where to attach and where to cascade to.And they're super hard on debugging and reasoning about code.Now sometimes they can be used in relatively limited scenarios where the structure of the code limits some of these problems. In UIs, cascading events can be used to trigger down the hierarchy because that hierarchy structure helps limit ownership and looping concerns.Still, I find far more often these days that I accept a delegate in a constructor for that sort of extensible behavior than let arbitrary behavior latch on at runtime.