Is it better to put an event on the top object or closer to where it's local?

Question

Take the following basic structured code for example:

class Player
{
   public QuestLog QuestLog { get; set; }
}

Let us consider that "QuestLog" has the ability to fire off some events when things are added or removed from it. Normally, I would subscribe directly to the QuestLog, such as doing something like:

player.QuestLog.AcceptedQuest += SomeHandler

However, I want to pass in some extra context (the player object). I saw a couple options.

1. Creating a lambda handler function which can resolve an extra parameter to the handler. This works but has some quirks I don't like. I'm currently using this approach.
2. I could couple the QuestLog to a Player, passing a reference of the player it belongs to in and fire events off accordingly with it. Feels like needless coupling.
3. Expose the event on the Player object itself as well as the QuestLog and 'bubble' the event up into where the context is available, thus allowing subscriptions directly onto player.

Keep in mind a player may have a few collections and a few events, so moving them all up might cause a couple dozen events to be held on one class.

How is this usually handled?

Answer 1

Creating a lambda handler function which can resolve an extra parameter to the handler. This works but has some quirks I don't like. I'm currently using this approach.

What don't you like? By keeping the signature small, and letting the handler be aware of the things it needs (but the event firing object needs to not know) you very effectively separate knowledge to where it needs to go.

I could couple the QuestLog to a Player, passing a reference of the player it belongs to in and fire events off accordingly with it. Feels like needless coupling.

Since players already have QuestLogs, then I'd argue that the coupling already exists to some degree. Further, if your handler wants to know that, that just reinforces that notion.

Coupling isn't always bad. Some things really should depend on one another and a clean design will couple those things together cohesively so that it's simple, clean, and robust.

Expose the event on the Player object itself as well as the QuestLog and 'bubble' the event up into where the context is available, thus allowing subscriptions directly onto player.

Sometimes good, but often a sign that you've got the event in the wrong place. This leaks implementation details (or at least it would if you didn't have QuestLog on the player publically, encouraging users to violate the Law of Demeter...).

But getting back to my comment, events have largely fallen out of favor for doing non-UI logic. Events, by their nature cause temporal coupling (you need to do things at the right time, in the right order for them to work properly). Events protect invariants poorly, and tend to leak through abstractions. They're fragile, they're fairly hard to test, they require some mediator to add/remove the event, they're the primary cause of memory leaks...

More often, delegates (or the dependencies themselves) are passed directly into the constructor so that the handler is known at construction time. You can't misuse the class if it's built to work from the start.

That or things work on a pull rather than push mechanism. Something checks the state every frame or some other timeframe (optionally checking some dirty flag which is pushed). This makes it easier to ignore the timing of things in many cases, making parallelism much more viable.