When Bother with Events

When "you aren't gonna need it" (YAGNI) and when you do actually need events.

The scenario is this: we have to call some functionality. You have a caller invoking a callee. The simplest approach is a direct call (synchronous or asynchronous), so we default to this whenever possible.

When You Better Do With Events

The following 4 practical scenarios - the rules of thumb - to decide if we actually have to bother with events. The scenarios effectively cover all the major reasons for using events.

1. Long wait for a callee operation result: Implement a long-running task in a callee; in a caller, fire the event the callee will listen to and execute the task on it. Treat the results in different parts of your application;

2. Many callees exist: Avoid the complexity of managing multiple direct calls to different callees, make them listen and act on the same (or a few) event(s) and let the caller fire the event(s);

3. Unknown event receivers: allows adding new listeners without modifying the caller's code. Let the caller fire the event and forget. Other places in the application will have to take care of the results.

4. Resilience: A failing callee must not break the caller. Or the caller does not want to bother with the errors processing. So it fires the event and lets the callee treat errors as it sees fit;

All the basic principles - SoC ¹, SRP ², low coupling ³ - high cohesion ⁴ - are fully applied here. But in daily practice, based on these, we need comfortably clear rules of thumb.

Now you have got these :)